All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, alsa-devel,
	coresight, dri-devel, intel-gfx, intel-wired-lan, keyrings, kvm,
	linux-acpi, linux-arm-kernel, linux-edac, linux-ext4,
	linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('©'): COPYRIGHT SIGN
	- U+00ac ('¬'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('®'): REGISTERED SIGN
	- U+00b0 ('°'): DEGREE SIGN
	- U+00b1 ('±'): PLUS-MINUS SIGN
	- U+00b2 ('²'): SUPERSCRIPT TWO
	- U+00b5 ('µ'): MICRO SIGN
	- U+00b7 ('·'): MIDDLE DOT		# See below
	- U+00bd ('½'): VULGAR FRACTION ONE HALF
	- U+00c7 ('Ç'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('ß'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('á'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('ä'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('æ'): LATIN SMALL LETTER AE
	- U+00e7 ('ç'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('é'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('ê'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('ë'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('ó'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('ô'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('ö'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('ø'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('ú'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('ü'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('ý'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('ğ'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('ł'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('μ'): GREEK SMALL LETTER MU
	- U+2026 ('…'): HORIZONTAL ELLIPSIS
	- U+2122 ('™'): TRADE MARK SIGN
	- U+2191 ('↑'): UPWARDS ARROW
	- U+2192 ('→'): RIGHTWARDS ARROW
	- U+2193 ('↓'): DOWNWARDS ARROW
	- U+2264 ('≤'): LESS-THAN OR EQUAL TO
	- U+2265 ('≥'): GREATER-THAN OR EQUAL TO
	- U+2500 ('─'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('│'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('└'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('├'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('·'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2



^ permalink raw reply	[flat|nested] 219+ messages in thread

* [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, alsa-devel,
	coresight, dri-devel, intel-gfx, intel-wired-lan, keyrings, kvm,
	linux-acpi, linux-arm-kernel, linux-edac, linux-ext4,
	linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('©'): COPYRIGHT SIGN
	- U+00ac ('¬'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('®'): REGISTERED SIGN
	- U+00b0 ('°'): DEGREE SIGN
	- U+00b1 ('±'): PLUS-MINUS SIGN
	- U+00b2 ('²'): SUPERSCRIPT TWO
	- U+00b5 ('µ'): MICRO SIGN
	- U+00b7 ('·'): MIDDLE DOT		# See below
	- U+00bd ('½'): VULGAR FRACTION ONE HALF
	- U+00c7 ('Ç'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('ß'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('á'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('ä'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('æ'): LATIN SMALL LETTER AE
	- U+00e7 ('ç'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('é'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('ê'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('ë'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('ó'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('ô'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('ö'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('ø'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('ú'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('ü'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('ý'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('ğ'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('ł'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('μ'): GREEK SMALL LETTER MU
	- U+2026 ('…'): HORIZONTAL ELLIPSIS
	- U+2122 ('™'): TRADE MARK SIGN
	- U+2191 ('↑'): UPWARDS ARROW
	- U+2192 ('→'): RIGHTWARDS ARROW
	- U+2193 ('↓'): DOWNWARDS ARROW
	- U+2264 ('≤'): LESS-THAN OR EQUAL TO
	- U+2265 ('≥'): GREATER-THAN OR EQUAL TO
	- U+2500 ('─'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('│'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('└'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('├'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('·'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, Mauro Carvalho Chehab,
	x86, linux-acpi, intel-wired-lan, linux-input, linux-ext4,
	intel-gfx, linux-media, linux-pm, linux-sgx, coresight, rcu,
	mjpeg-users, linux-arm-kernel, linux-edac, linux-hwmon, netdev,
	linux-usb, linux-kernel, linux-f2fs-devel, linux-rdma,
	linux-integrity

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('©'): COPYRIGHT SIGN
	- U+00ac ('¬'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('®'): REGISTERED SIGN
	- U+00b0 ('°'): DEGREE SIGN
	- U+00b1 ('±'): PLUS-MINUS SIGN
	- U+00b2 ('²'): SUPERSCRIPT TWO
	- U+00b5 ('µ'): MICRO SIGN
	- U+00b7 ('·'): MIDDLE DOT		# See below
	- U+00bd ('½'): VULGAR FRACTION ONE HALF
	- U+00c7 ('Ç'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('ß'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('á'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('ä'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('æ'): LATIN SMALL LETTER AE
	- U+00e7 ('ç'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('é'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('ê'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('ë'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('ó'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('ô'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('ö'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('ø'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('ú'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('ü'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('ý'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('ğ'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('ł'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('μ'): GREEK SMALL LETTER MU
	- U+2026 ('…'): HORIZONTAL ELLIPSIS
	- U+2122 ('™'): TRADE MARK SIGN
	- U+2191 ('↑'): UPWARDS ARROW
	- U+2192 ('→'): RIGHTWARDS ARROW
	- U+2193 ('↓'): DOWNWARDS ARROW
	- U+2264 ('≤'): LESS-THAN OR EQUAL TO
	- U+2265 ('≥'): GREATER-THAN OR EQUAL TO
	- U+2500 ('─'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('│'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('└'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('├'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('·'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2




_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, Mauro Carvalho Chehab,
	x86, linux-acpi, intel-wired-lan, linux-input, linux-ext4,
	intel-gfx, linux-media, linux-pm, linux-sgx, coresight, rcu,
	mjpeg-users, linux-arm-kernel, linux-edac, linux-hwmon, netdev,
	linux-usb, linux-kernel, linux-f2fs-devel, linux-rdma,
	linux-integrity

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('©'): COPYRIGHT SIGN
	- U+00ac ('¬'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('®'): REGISTERED SIGN
	- U+00b0 ('°'): DEGREE SIGN
	- U+00b1 ('±'): PLUS-MINUS SIGN
	- U+00b2 ('²'): SUPERSCRIPT TWO
	- U+00b5 ('µ'): MICRO SIGN
	- U+00b7 ('·'): MIDDLE DOT		# See below
	- U+00bd ('½'): VULGAR FRACTION ONE HALF
	- U+00c7 ('Ç'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('ß'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('á'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('ä'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('æ'): LATIN SMALL LETTER AE
	- U+00e7 ('ç'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('é'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('ê'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('ë'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('ó'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('ô'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('ö'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('ø'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('ú'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('ü'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('ý'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('ğ'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('ł'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('μ'): GREEK SMALL LETTER MU
	- U+2026 ('…'): HORIZONTAL ELLIPSIS
	- U+2122 ('™'): TRADE MARK SIGN
	- U+2191 ('↑'): UPWARDS ARROW
	- U+2192 ('→'): RIGHTWARDS ARROW
	- U+2193 ('↓'): DOWNWARDS ARROW
	- U+2264 ('≤'): LESS-THAN OR EQUAL TO
	- U+2265 ('≥'): GREATER-THAN OR EQUAL TO
	- U+2500 ('─'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('│'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('└'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('├'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('·'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2



^ permalink raw reply	[flat|nested] 219+ messages in thread

* [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, alsa-devel,
	coresight, dri-devel, intel-gfx, intel-wired-lan, keyrings, kvm,
	linux-acpi, linux-arm-kernel, linux-edac, linux-ext4,
	linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('©'): COPYRIGHT SIGN
	- U+00ac ('¬'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('®'): REGISTERED SIGN
	- U+00b0 ('°'): DEGREE SIGN
	- U+00b1 ('±'): PLUS-MINUS SIGN
	- U+00b2 ('²'): SUPERSCRIPT TWO
	- U+00b5 ('µ'): MICRO SIGN
	- U+00b7 ('·'): MIDDLE DOT		# See below
	- U+00bd ('½'): VULGAR FRACTION ONE HALF
	- U+00c7 ('Ç'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('ß'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('á'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('ä'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('æ'): LATIN SMALL LETTER AE
	- U+00e7 ('ç'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('é'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('ê'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('ë'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('ó'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('ô'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('ö'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('ø'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('ú'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('ü'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('ý'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('ğ'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('ł'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('μ'): GREEK SMALL LETTER MU
	- U+2026 ('…'): HORIZONTAL ELLIPSIS
	- U+2122 ('™'): TRADE MARK SIGN
	- U+2191 ('↑'): UPWARDS ARROW
	- U+2192 ('→'): RIGHTWARDS ARROW
	- U+2193 ('↓'): DOWNWARDS ARROW
	- U+2264 ('≤'): LESS-THAN OR EQUAL TO
	- U+2265 ('≥'): GREATER-THAN OR EQUAL TO
	- U+2500 ('─'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('│'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('└'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('├'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('·'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, Mauro Carvalho Chehab,
	x86, linux-acpi, intel-wired-lan, linux-input, linux-ext4,
	intel-gfx, linux-media, linux-pm, linux-sgx, coresight, rcu,
	mjpeg-users, linux-arm-kernel, linux-edac, linux-hwmon, netdev,
	linux-usb, linux-kernel, linux-f2fs-devel, linux-rdma,
	linux-integrity

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('©'): COPYRIGHT SIGN
	- U+00ac ('¬'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('®'): REGISTERED SIGN
	- U+00b0 ('°'): DEGREE SIGN
	- U+00b1 ('±'): PLUS-MINUS SIGN
	- U+00b2 ('²'): SUPERSCRIPT TWO
	- U+00b5 ('µ'): MICRO SIGN
	- U+00b7 ('·'): MIDDLE DOT		# See below
	- U+00bd ('½'): VULGAR FRACTION ONE HALF
	- U+00c7 ('Ç'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('ß'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('á'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('ä'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('æ'): LATIN SMALL LETTER AE
	- U+00e7 ('ç'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('é'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('ê'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('ë'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('ó'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('ô'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('ö'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('ø'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('ú'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('ü'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('ý'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('ğ'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('ł'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('μ'): GREEK SMALL LETTER MU
	- U+2026 ('…'): HORIZONTAL ELLIPSIS
	- U+2122 ('™'): TRADE MARK SIGN
	- U+2191 ('↑'): UPWARDS ARROW
	- U+2192 ('→'): RIGHTWARDS ARROW
	- U+2193 ('↓'): DOWNWARDS ARROW
	- U+2264 ('≤'): LESS-THAN OR EQUAL TO
	- U+2265 ('≥'): GREATER-THAN OR EQUAL TO
	- U+2500 ('─'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('│'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('└'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('├'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('·'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: intel-wired-lan

There are several UTF-8 characters at the Kernel's documentation.

Several of them were due to the process of converting files from
DocBook, LaTeX, HTML and Markdown. They were probably introduced
by the conversion tools used on that time.

Other UTF-8 characters were added along the time, but they're easily
replaceable by ASCII chars.

As Linux developers are all around the globe, and not everybody has UTF-8
as their default charset, better to use UTF-8 only on cases where it is really
needed.

The first 3 patches on this series were manually written, in order to solve
a few special cases.

The remaining patches on series address such cases on *.rst files and 
inside the Documentation/ABI, using this perl map table in order to do the
charset conversion:

my %char_map = (
	0x2010 => '-',		# HYPHEN
	0xad   => '-',		# SOFT HYPHEN
	0x2013 => '-',		# EN DASH
	0x2014 => '-',		# EM DASH

	0x2018 => "'",		# LEFT SINGLE QUOTATION MARK
	0x2019 => "'",		# RIGHT SINGLE QUOTATION MARK
	0xb4   => "'",		# ACUTE ACCENT

	0x201c => '"',		# LEFT DOUBLE QUOTATION MARK
	0x201d => '"',		# RIGHT DOUBLE QUOTATION MARK

	0x2212 => '-',		# MINUS SIGN
	0x2217 => '*',		# ASTERISK OPERATOR
	0xd7   => 'x',		# MULTIPLICATION SIGN

	0xbb   => '>',		# RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

	0xa0   => ' ',		# NO-BREAK SPACE
	0xfeff => '',		# ZERO WIDTH NO-BREAK SPACE
);

After the conversion, those UTF-8 chars will be kept:

	- U+00a9 ('?'): COPYRIGHT SIGN
	- U+00ac ('?'): NOT SIGN		# only at Documentation/powerpc/transactional_memory.rst
	- U+00ae ('?'): REGISTERED SIGN
	- U+00b0 ('?'): DEGREE SIGN
	- U+00b1 ('?'): PLUS-MINUS SIGN
	- U+00b2 ('?'): SUPERSCRIPT TWO
	- U+00b5 ('?'): MICRO SIGN
	- U+00b7 ('?'): MIDDLE DOT		# See below
	- U+00bd ('?'): VULGAR FRACTION ONE HALF
	- U+00c7 ('?'): LATIN CAPITAL LETTER C WITH CEDILLA
	- U+00df ('?'): LATIN SMALL LETTER SHARP S
	- U+00e1 ('?'): LATIN SMALL LETTER A WITH ACUTE
	- U+00e4 ('?'): LATIN SMALL LETTER A WITH DIAERESIS
	- U+00e6 ('?'): LATIN SMALL LETTER AE
	- U+00e7 ('?'): LATIN SMALL LETTER C WITH CEDILLA
	- U+00e9 ('?'): LATIN SMALL LETTER E WITH ACUTE
	- U+00ea ('?'): LATIN SMALL LETTER E WITH CIRCUMFLEX
	- U+00eb ('?'): LATIN SMALL LETTER E WITH DIAERESIS
	- U+00f3 ('?'): LATIN SMALL LETTER O WITH ACUTE
	- U+00f4 ('?'): LATIN SMALL LETTER O WITH CIRCUMFLEX
	- U+00f6 ('?'): LATIN SMALL LETTER O WITH DIAERESIS
	- U+00f8 ('?'): LATIN SMALL LETTER O WITH STROKE
	- U+00fa ('?'): LATIN SMALL LETTER U WITH ACUTE
	- U+00fc ('?'): LATIN SMALL LETTER U WITH DIAERESIS
	- U+00fd ('?'): LATIN SMALL LETTER Y WITH ACUTE
	- U+011f ('?'): LATIN SMALL LETTER G WITH BREVE
	- U+0142 ('?'): LATIN SMALL LETTER L WITH STROKE
	- U+03bc ('?'): GREEK SMALL LETTER MU
	- U+2026 ('?'): HORIZONTAL ELLIPSIS
	- U+2122 ('?'): TRADE MARK SIGN
	- U+2191 ('?'): UPWARDS ARROW
	- U+2192 ('?'): RIGHTWARDS ARROW
	- U+2193 ('?'): DOWNWARDS ARROW
	- U+2264 ('?'): LESS-THAN OR EQUAL TO
	- U+2265 ('?'): GREATER-THAN OR EQUAL TO
	- U+2500 ('?'): BOX DRAWINGS LIGHT HORIZONTAL
	- U+2502 ('?'): BOX DRAWINGS LIGHT VERTICAL
	- U+2514 ('?'): BOX DRAWINGS LIGHT UP AND RIGHT
	- U+251c ('?'): BOX DRAWINGS LIGHT VERTICAL AND RIGHT
	- U+2b0d ('?'): UP DOWN BLACK ARROW

PS.: maintainers were bcc on patch 00/53, in order to reduce the
risk of patch 00 to be rejected by list servers.

-

For U+00b7 ('?'): MIDDLE DOT, I opted to keep it on a few places:

- Documentation/devicetree/bindings/clock/qcom,rpmcc.txt

  As this file will be some day converted to yaml, where the 
  MIDDLE DOT will be removed, I guess it is not worth touching it.

- Documentation/scheduler/sched-deadline.rst

  There, it is used on a math expressions. So, better to keep.

- Documentation/devicetree/bindings/media/video-interface-devices.yaml

  There, it part of an ASCII artwork.

- translations/zh_CN

  I prefer not touching it, as it might have some special meaning in Simplified Chinese.

Mauro Carvalho Chehab (53):
  docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  docs: ABI: remove a meaningless UTF-8 character
  docs: ABI: remove some spurious characters
  docs: index.rst: avoid using UTF-8 chars
  docs: hwmon: avoid using UTF-8 chars
  docs: admin-guide: avoid using UTF-8 chars
  docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  docs: admin-guide: pm: avoid using UTF-8 chars
  docs: trace: coresight: coresight-etm4x-reference.rst: avoid using
    UTF-8 chars
  docs: driver-api: avoid using UTF-8 chars
  docs: driver-api: fpga: avoid using UTF-8 chars
  docs: driver-api: iio: avoid using UTF-8 chars
  docs: driver-api: thermal: avoid using UTF-8 chars
  docs: driver-api: media: drivers: avoid using UTF-8 chars
  docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8
    chars
  docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8
    chars
  docs: usb: avoid using UTF-8 chars
  docs: process: avoid using UTF-8 chars
  docs: block: data-integrity.rst: avoid using UTF-8 chars
  docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  docs: userspace-api: media: v4l: avoid using UTF-8 chars
  docs: userspace-api: media: dvb: avoid using UTF-8 chars
  docs: vm: zswap.rst: avoid using UTF-8 chars
  docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  docs: filesystems: ext4: avoid using UTF-8 chars
  docs: kernel-hacking: avoid using UTF-8 chars
  docs: hid: avoid using UTF-8 chars
  docs: security: tpm: avoid using UTF-8 chars
  docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  docs: networking: scaling.rst: avoid using UTF-8 chars
  docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  docs: networking: device_drivers: avoid using UTF-8 chars
  docs: x86: avoid using UTF-8 chars
  docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  docs: ABI: avoid using UTF-8 chars
  docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  docs: gpu: avoid using UTF-8 chars
  docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8
    chars
  docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  docs: timers: no_hz.rst: avoid using UTF-8 chars
  docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  docs: virt: kvm: avoid using UTF-8 chars
  docs: RCU: avoid using UTF-8 chars

 .../obsolete/sysfs-kernel-fadump_registered   |   2 +-
 .../obsolete/sysfs-kernel-fadump_release_mem  |   2 +-
 ...sfs-class-chromeos-driver-cros-ec-lightbar |   2 +-
 .../ABI/testing/sysfs-class-net-cdc_ncm       |   2 +-
 .../ABI/testing/sysfs-devices-platform-ipmi   |   2 +-
 .../testing/sysfs-devices-platform-trackpoint |   2 +-
 Documentation/ABI/testing/sysfs-devices-soc   |   4 +-
 Documentation/ABI/testing/sysfs-module        |   4 +-
 Documentation/PCI/acpi-info.rst               |  26 +-
 .../Data-Structures/Data-Structures.rst       |  52 ++--
 .../Expedited-Grace-Periods.rst               |  40 +--
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 ++++-----
 Documentation/admin-guide/index.rst           |   2 +-
 Documentation/admin-guide/media/ipu3.rst      |   2 +-
 Documentation/admin-guide/module-signing.rst  |   4 +-
 Documentation/admin-guide/perf/imx-ddr.rst    |   2 +-
 Documentation/admin-guide/pm/intel_idle.rst   |   4 +-
 Documentation/admin-guide/pm/intel_pstate.rst |   4 +-
 Documentation/admin-guide/ras.rst             |  94 +++----
 .../admin-guide/reporting-issues.rst          |  12 +-
 Documentation/admin-guide/sysctl/kernel.rst   |   2 +-
 Documentation/arm64/arm-acpi.rst              |   8 +-
 Documentation/block/data-integrity.rst        |   2 +-
 Documentation/cdrom/cdrom-standard.rst        |  30 +--
 Documentation/dev-tools/testing-overview.rst  |   4 +-
 Documentation/doc-guide/contributing.rst      |   2 +-
 .../driver-api/firmware/other_interfaces.rst  |   2 +-
 Documentation/driver-api/fpga/fpga-bridge.rst |  10 +-
 Documentation/driver-api/fpga/fpga-mgr.rst    |  12 +-
 .../driver-api/fpga/fpga-programming.rst      |   8 +-
 Documentation/driver-api/fpga/fpga-region.rst |  20 +-
 Documentation/driver-api/iio/buffers.rst      |   8 +-
 Documentation/driver-api/iio/hw-consumer.rst  |  10 +-
 .../driver-api/iio/triggered-buffers.rst      |   6 +-
 Documentation/driver-api/iio/triggers.rst     |  10 +-
 Documentation/driver-api/index.rst            |   2 +-
 Documentation/driver-api/ioctl.rst            |   8 +-
 .../media/drivers/sh_mobile_ceu_camera.rst    |   8 +-
 .../driver-api/media/drivers/vidtv.rst        |   4 +-
 .../driver-api/media/drivers/zoran.rst        |   2 +-
 Documentation/driver-api/nvdimm/btt.rst       |   2 +-
 .../driver-api/thermal/cpu-idle-cooling.rst   |  14 +-
 .../driver-api/thermal/intel_powerclamp.rst   |   6 +-
 .../thermal/x86_pkg_temperature_thermal.rst   |   2 +-
 .../fault-injection/nvme-fault-injection.rst  |   2 +-
 Documentation/filesystems/ext4/attributes.rst |  20 +-
 Documentation/filesystems/ext4/bigalloc.rst   |   6 +-
 Documentation/filesystems/ext4/blockgroup.rst |   8 +-
 Documentation/filesystems/ext4/blocks.rst     |   2 +-
 Documentation/filesystems/ext4/directory.rst  |  16 +-
 Documentation/filesystems/ext4/eainode.rst    |   2 +-
 Documentation/filesystems/ext4/inlinedata.rst |   6 +-
 Documentation/filesystems/ext4/inodes.rst     |   6 +-
 Documentation/filesystems/ext4/journal.rst    |   8 +-
 Documentation/filesystems/ext4/mmp.rst        |   2 +-
 .../filesystems/ext4/special_inodes.rst       |   4 +-
 Documentation/filesystems/ext4/super.rst      |  10 +-
 Documentation/filesystems/f2fs.rst            |   6 +-
 .../firmware-guide/acpi/dsd/graph.rst         |   2 +-
 Documentation/firmware-guide/acpi/lpit.rst    |   2 +-
 Documentation/gpu/i915.rst                    |   2 +-
 Documentation/gpu/komeda-kms.rst              |   2 +-
 Documentation/hid/hid-sensor.rst              |  70 ++---
 Documentation/hid/intel-ish-hid.rst           | 246 +++++++++---------
 Documentation/hwmon/ir36021.rst               |   2 +-
 Documentation/hwmon/ltc2992.rst               |   2 +-
 Documentation/hwmon/pm6764tr.rst              |   2 +-
 Documentation/hwmon/tmp103.rst                |   4 +-
 Documentation/index.rst                       |   4 +-
 Documentation/infiniband/tag_matching.rst     |   8 +-
 Documentation/kernel-hacking/hacking.rst      |   2 +-
 Documentation/kernel-hacking/locking.rst      |   2 +-
 Documentation/misc-devices/ibmvmc.rst         |   8 +-
 .../device_drivers/ethernet/intel/i40e.rst    |  12 +-
 .../device_drivers/ethernet/intel/iavf.rst    |   6 +-
 .../device_drivers/ethernet/netronome/nfp.rst |  12 +-
 .../networking/devlink/devlink-dpipe.rst      |   2 +-
 Documentation/networking/scaling.rst          |  18 +-
 Documentation/power/powercap/powercap.rst     | 210 +++++++--------
 Documentation/process/code-of-conduct.rst     |   2 +-
 .../process/kernel-enforcement-statement.rst  |   2 +-
 Documentation/riscv/vm-layout.rst             |   2 +-
 Documentation/scheduler/sched-deadline.rst    |   4 +-
 .../security/keys/trusted-encrypted.rst       |   4 +-
 Documentation/security/tpm/tpm_event_log.rst  |   2 +-
 Documentation/security/tpm/xen-tpmfront.rst   |   2 +-
 .../kernel-api/writing-an-alsa-driver.rst     |  68 ++---
 Documentation/timers/no_hz.rst                |   2 +-
 .../coresight/coresight-etm4x-reference.rst   |  16 +-
 Documentation/usb/ehci.rst                    |   2 +-
 Documentation/usb/gadget_printer.rst          |   2 +-
 Documentation/usb/mass-storage.rst            |  36 +--
 Documentation/usb/mtouchusb.rst               |   2 +-
 Documentation/usb/usb-serial.rst              |   2 +-
 .../media/dvb/audio-set-bypass-mode.rst       |   2 +-
 .../userspace-api/media/dvb/audio.rst         |   2 +-
 .../userspace-api/media/dvb/dmx-fopen.rst     |   2 +-
 .../userspace-api/media/dvb/dmx-fread.rst     |   2 +-
 .../media/dvb/dmx-set-filter.rst              |   2 +-
 .../userspace-api/media/dvb/intro.rst         |   6 +-
 .../userspace-api/media/dvb/video.rst         |   2 +-
 .../userspace-api/media/fdl-appendix.rst      |  64 ++---
 .../userspace-api/media/v4l/biblio.rst        |   8 +-
 .../userspace-api/media/v4l/crop.rst          |  16 +-
 .../userspace-api/media/v4l/dev-decoder.rst   |   6 +-
 .../userspace-api/media/v4l/diff-v4l.rst      |   2 +-
 .../userspace-api/media/v4l/open.rst          |   2 +-
 .../media/v4l/vidioc-cropcap.rst              |   4 +-
 Documentation/virt/kvm/api.rst                |  28 +-
 .../virt/kvm/running-nested-guests.rst        |  12 +-
 Documentation/vm/zswap.rst                    |   4 +-
 Documentation/x86/resctrl.rst                 |   2 +-
 Documentation/x86/sgx.rst                     |   4 +-
 114 files changed, 807 insertions(+), 807 deletions(-)

-- 
2.30.2



^ permalink raw reply	[flat|nested] 219+ messages in thread

* [PATCH 01/53] docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (5 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Jens Axboe, linux-kernel

This file was converted from a LaTeX one. The conversion used
some UTF-8 characters at the literal blocks. Replace them
by normal ASCII characters.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/cdrom/cdrom-standard.rst | 30 +++++++++++++-------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst
index 70500b189cc8..5845960ca382 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -146,18 +146,18 @@ with the kernel as a block device by registering the following general
 *struct file_operations*::
 
 	struct file_operations cdrom_fops = {
-		NULL,			/∗ lseek ∗/
-		block _read ,		/∗ read—general block-dev read ∗/
-		block _write,		/∗ write—general block-dev write ∗/
-		NULL,			/∗ readdir ∗/
-		NULL,			/∗ select ∗/
-		cdrom_ioctl,		/∗ ioctl ∗/
-		NULL,			/∗ mmap ∗/
-		cdrom_open,		/∗ open ∗/
-		cdrom_release,		/∗ release ∗/
-		NULL,			/∗ fsync ∗/
-		NULL,			/∗ fasync ∗/
-		NULL			/∗ revalidate ∗/
+		NULL,			/* lseek */
+		block _read ,		/* read--general block-dev read */
+		block _write,		/* write--general block-dev write */
+		NULL,			/* readdir */
+		NULL,			/* select */
+		cdrom_ioctl,		/* ioctl */
+		NULL,			/* mmap */
+		cdrom_open,		/* open */
+		cdrom_release,		/* release */
+		NULL,			/* fsync */
+		NULL,			/* fasync */
+		NULL			/* revalidate */
 	};
 
 Every active CD-ROM device shares this *struct*. The routines
@@ -250,12 +250,12 @@ The drive-specific, minor-like information that is registered with
 `cdrom.c`, currently contains the following fields::
 
   struct cdrom_device_info {
-	const struct cdrom_device_ops * ops; 	/* device operations for this major */
+	const struct cdrom_device_ops * ops;	/* device operations for this major */
 	struct list_head list;			/* linked list of all device_info */
 	struct gendisk * disk;			/* matching block layer disk */
 	void *  handle;				/* driver-dependent data */
 
-	int mask; 				/* mask of capability: disables them */
+	int mask;				/* mask of capability: disables them */
 	int speed;				/* maximum speed for reading data */
 	int capacity;				/* number of discs in a jukebox */
 
@@ -569,7 +569,7 @@ the *CDC_CLOSE_TRAY* bit in *mask*.
 
 In the file `cdrom.c` you will encounter many constructions of the type::
 
-	if (cdo->capability & ∼cdi->mask & CDC _⟨capability⟩) ...
+	if (cdo->capability & ~cdi->mask & CDC _<capability>) ...
 
 There is no *ioctl* to set the mask... The reason is that
 I think it is better to control the **behavior** rather than the
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 02/53] docs: ABI: remove a meaningless UTF-8 character
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (6 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

Those two files have this character:
	- U+00ac ('¬'): NOT SIGN

at the end of the first line, apparently for no reason. Drop them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/ABI/obsolete/sysfs-kernel-fadump_registered  | 2 +-
 Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered b/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered
index 0360be39c98e..dae880b1a5d5 100644
--- a/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered
+++ b/Documentation/ABI/obsolete/sysfs-kernel-fadump_registered
@@ -1,4 +1,4 @@
-This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬
+This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.
 
 What:		/sys/kernel/fadump_registered
 Date:		Feb 2012
diff --git a/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem b/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem
index 6ce0b129ab12..ca2396edb5f1 100644
--- a/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem
+++ b/Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem
@@ -1,4 +1,4 @@
-This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬
+This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.
 
 What:		/sys/kernel/fadump_release_mem
 Date:		Feb 2012
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 03/53] docs: ABI: remove some spurious characters
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (7 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Cezary Rojewski,
	Geert Uytterhoeven, Suzuki K Poulose, Vaibhav Jain, linux-kernel

The KernelVersion tag contains some spurious UTF-8 characters
for no reason. Drop them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/ABI/testing/sysfs-module | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module
index a485434d2a0f..88bddf192ceb 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -37,13 +37,13 @@ Description:	Maximum time allowed for periodic transfers per microframe (μs)
 
 What:		/sys/module/*/{coresize,initsize}
 Date:		Jan 2012
-KernelVersion:»·3.3
+KernelVersion:	3.3
 Contact:	Kay Sievers <kay.sievers@vrfy.org>
 Description:	Module size in bytes.
 
 What:		/sys/module/*/taint
 Date:		Jan 2012
-KernelVersion:»·3.3
+KernelVersion:	3.3
 Contact:	Kay Sievers <kay.sievers@vrfy.org>
 Description:	Module taint flags:
 			==  =====================
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 04/53] docs: index.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (8 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/index.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 54ce34fd6fbd..11cd806ea3a4 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel — those who are
+The following manuals are written for *users* of the kernel - those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it — probably *not* all that is
+as needed (or at least as we managed to add it - probably *not* all that is
 needed).
 
 .. toctree::
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 05/53] docs: hwmon: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (9 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 13:30   ` Guenter Roeck
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Charles Hsu,
	Guenter Roeck, Jean Delvare, linux-hwmon, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2010 ('‐'): HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/hwmon/ir36021.rst  | 2 +-
 Documentation/hwmon/ltc2992.rst  | 2 +-
 Documentation/hwmon/pm6764tr.rst | 2 +-
 Documentation/hwmon/tmp103.rst   | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwmon/ir36021.rst b/Documentation/hwmon/ir36021.rst
index ca3436b04e20..1faa85c39f1b 100644
--- a/Documentation/hwmon/ir36021.rst
+++ b/Documentation/hwmon/ir36021.rst
@@ -19,7 +19,7 @@ Authors:
 Description
 -----------
 
-The IR36021 is a dual‐loop digital multi‐phase buck controller designed for
+The IR36021 is a dual-loop digital multi-phase buck controller designed for
 point of load applications.
 
 Usage Notes
diff --git a/Documentation/hwmon/ltc2992.rst b/Documentation/hwmon/ltc2992.rst
index 46aa1aa84a1a..a0bcd867a0f5 100644
--- a/Documentation/hwmon/ltc2992.rst
+++ b/Documentation/hwmon/ltc2992.rst
@@ -19,7 +19,7 @@ This driver supports hardware monitoring for Linear Technology LTC2992 power mon
 LTC2992 is a rail-to-rail system monitor that measures current,
 voltage, and power of two supplies.
 
-Two ADCs simultaneously measure each supply’s current. A third ADC monitors
+Two ADCs simultaneously measure each supply's current. A third ADC monitors
 the input voltages and four auxiliary external voltages.
 
 
diff --git a/Documentation/hwmon/pm6764tr.rst b/Documentation/hwmon/pm6764tr.rst
index a1fb8fea2326..294a8ffc8bd8 100644
--- a/Documentation/hwmon/pm6764tr.rst
+++ b/Documentation/hwmon/pm6764tr.rst
@@ -20,7 +20,7 @@ Description:
 ------------
 
 This driver supports the STMicroelectronics PM6764TR chip. The PM6764TR is a high
-performance digital controller designed to power Intel’s VR12.5 processors and memories.
+performance digital controller designed to power Intel's VR12.5 processors and memories.
 
 The device utilizes digital technology to implement all control and power management
 functions to provide maximum flexibility and performance. The NVM is embedded to store
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index e195a7d14309..b3ef81475cf8 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of –40°C to +125°C.
+operation over a temperature range of -40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (–10°C to +100°C)
+Accuracy: ±1°C Typ (-10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 06/53] docs: admin-guide: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (10 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 18:40   ` Gabriel Krisman Bertazi
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Daniel W. S. Almeida, Jonathan Corbet,
	Arnd Bergmann, Borislav Petkov, David Howells, David Woodhouse,
	Gabriel Krisman Bertazi, Greg Kroah-Hartman, James Morse,
	Kees Cook, Mauro Carvalho Chehab, Robert Richter,
	Thorsten Leemhuis, Tony Luck, keyrings, linux-edac, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/index.rst           |  2 +-
 Documentation/admin-guide/module-signing.rst  |  4 +-
 Documentation/admin-guide/ras.rst             | 94 +++++++++----------
 .../admin-guide/reporting-issues.rst          | 12 +--
 4 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index dc00afcabb95..b1692643718d 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here — this material was not written to be a single, coherent
+organization here - this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index 7d7c7c8a545c..bd1d2fef78e8 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or — on systems where
-     the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or - on systems where
+     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 7b481b2a368e..00445adf8708 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU – detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory – add error correction logic (ECC) to detect and correct errors;
-* I/O – add CRC checksums for transferred data;
-* Storage – RAID, journal file systems, checksums,
+* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory - add error correction logic (ECC) to detect and correct errors;
+* I/O - add CRC checksums for transferred data;
+* Storage - RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
@@ -443,49 +443,49 @@ A typical EDAC system has the following structure under
 
 	/sys/devices/system/edac/
 	├── mc
-	│   ├── mc0
-	│   │   ├── ce_count
-	│   │   ├── ce_noinfo_count
-	│   │   ├── dimm0
-	│   │   │   ├── dimm_ce_count
-	│   │   │   ├── dimm_dev_type
-	│   │   │   ├── dimm_edac_mode
-	│   │   │   ├── dimm_label
-	│   │   │   ├── dimm_location
-	│   │   │   ├── dimm_mem_type
-	│   │   │   ├── dimm_ue_count
-	│   │   │   ├── size
-	│   │   │   └── uevent
-	│   │   ├── max_location
-	│   │   ├── mc_name
-	│   │   ├── reset_counters
-	│   │   ├── seconds_since_reset
-	│   │   ├── size_mb
-	│   │   ├── ue_count
-	│   │   ├── ue_noinfo_count
-	│   │   └── uevent
-	│   ├── mc1
-	│   │   ├── ce_count
-	│   │   ├── ce_noinfo_count
-	│   │   ├── dimm0
-	│   │   │   ├── dimm_ce_count
-	│   │   │   ├── dimm_dev_type
-	│   │   │   ├── dimm_edac_mode
-	│   │   │   ├── dimm_label
-	│   │   │   ├── dimm_location
-	│   │   │   ├── dimm_mem_type
-	│   │   │   ├── dimm_ue_count
-	│   │   │   ├── size
-	│   │   │   └── uevent
-	│   │   ├── max_location
-	│   │   ├── mc_name
-	│   │   ├── reset_counters
-	│   │   ├── seconds_since_reset
-	│   │   ├── size_mb
-	│   │   ├── ue_count
-	│   │   ├── ue_noinfo_count
-	│   │   └── uevent
-	│   └── uevent
+	│   ├── mc0
+	│   │   ├── ce_count
+	│   │   ├── ce_noinfo_count
+	│   │   ├── dimm0
+	│   │   │   ├── dimm_ce_count
+	│   │   │   ├── dimm_dev_type
+	│   │   │   ├── dimm_edac_mode
+	│   │   │   ├── dimm_label
+	│   │   │   ├── dimm_location
+	│   │   │   ├── dimm_mem_type
+	│   │   │   ├── dimm_ue_count
+	│   │   │   ├── size
+	│   │   │   └── uevent
+	│   │   ├── max_location
+	│   │   ├── mc_name
+	│   │   ├── reset_counters
+	│   │   ├── seconds_since_reset
+	│   │   ├── size_mb
+	│   │   ├── ue_count
+	│   │   ├── ue_noinfo_count
+	│   │   └── uevent
+	│   ├── mc1
+	│   │   ├── ce_count
+	│   │   ├── ce_noinfo_count
+	│   │   ├── dimm0
+	│   │   │   ├── dimm_ce_count
+	│   │   │   ├── dimm_dev_type
+	│   │   │   ├── dimm_edac_mode
+	│   │   │   ├── dimm_label
+	│   │   │   ├── dimm_location
+	│   │   │   ├── dimm_mem_type
+	│   │   │   ├── dimm_ue_count
+	│   │   │   ├── size
+	│   │   │   └── uevent
+	│   │   ├── max_location
+	│   │   ├── mc_name
+	│   │   ├── reset_counters
+	│   │   ├── seconds_since_reset
+	│   │   ├── size_mb
+	│   │   ├── ue_count
+	│   │   ├── ue_noinfo_count
+	│   │   └── uevent
+	│   └── uevent
 	└── uevent
 
 In the ``dimmX`` directories are EDAC control and attribute files for
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index 18d8e25ba9df..f691930e13c0 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable — and you
+that 'rc' scare you, these 'development kernels' are pretty reliable - and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing — especially is you are unfamiliar with the Linux kernel. The
+way for testing - especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1248,7 +1248,7 @@ paragraph makes the severeness obvious.
 
 In case you performed a successful bisection, use the title of the change that
 introduced the regression as the second part of your subject. Make the report
-also mention the commit id of the culprit. In case of an unsuccessful bisection,
+also mention the commit id of the culprit. In case of an unsuccessful bisection,
 make your report mention the latest tested version that's working fine (say 5.7)
 and the oldest where the issue occurs (say 5.8-rc1).
 
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone – one
+are scattered around the globe and thus might be in a different time zone - one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying —
+issues are normally reported in public it could be anyone that's replying -
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer – and nobody can be forced
+nobody is willing to take over the job as maintainer - and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 07/53] docs: admin-guide: media: ipu3.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (11 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Bingbu Cao,
	Mauro Carvalho Chehab, Sakari Ailus, Tianshu Qiu, linux-kernel,
	linux-media

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/media/ipu3.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst
index f59697c7b374..f77cb1384dc3 100644
--- a/Documentation/admin-guide/media/ipu3.rst
+++ b/Documentation/admin-guide/media/ipu3.rst
@@ -244,7 +244,7 @@ larger bayer frame for further YUV processing than "VIDEO" mode to get high
 quality images. Besides, "STILL" mode need XNR3 to do noise reduction, hence
 "STILL" mode will need more power and memory bandwidth than "VIDEO" mode. TNR
 will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is running at
-“VIDEO” mode by default, the user can use v4l2 control V4L2_CID_INTEL_IPU3_MODE
+"VIDEO" mode by default, the user can use v4l2 control V4L2_CID_INTEL_IPU3_MODE
 (currently defined in drivers/staging/media/ipu3/include/intel-ipu3.h) to query
 and set the running mode. For user, there is no difference for buffer queueing
 between the "VIDEO" and "STILL" mode, mandatory input and main output node
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 08/53] docs: admin-guide: sysctl: kernel.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (12 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Guilherme G. Piccoli, Jonathan Corbet,
	Andrew Morton, Kees Cook, Qais Yousef, Rafael Aquini,
	Randy Dunlap, Stephen Kitt, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/sysctl/kernel.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 1d56a6b73a4e..743a7c70fd83 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog — if enabled — can
+the watchdog timer function, otherwise the NMI watchdog - if enabled - can
 detect a hard lockup condition.
 
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 09/53] docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Fabio Estevam, Frank Li,
	NXP Linux Team, Pengutronix Kernel Team, Sascha Hauer, Shawn Guo,
	linux-arm-kernel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/perf/imx-ddr.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
index 90926d0fb8ec..269d0b564903 100644
--- a/Documentation/admin-guide/perf/imx-ddr.rst
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -9,7 +9,7 @@ control register which causes a large number of PERF signals to be generated.
 
 Selection of the value for each counter is done via the config registers. There
 is one register for each counter. Counter 0 is special in that it always counts
-“time” and when expired causes a lock on itself and the other counters and an
+"time" and when expired causes a lock on itself and the other counters and an
 interrupt is raised. If any other counter overflows, it continues counting, and
 no interrupt is raised.
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 09/53] docs: admin-guide: perf: imx-ddr.rst: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Fabio Estevam, Frank Li,
	NXP Linux Team, Pengutronix Kernel Team, Sascha Hauer, Shawn Guo,
	linux-arm-kernel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/perf/imx-ddr.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
index 90926d0fb8ec..269d0b564903 100644
--- a/Documentation/admin-guide/perf/imx-ddr.rst
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -9,7 +9,7 @@ control register which causes a large number of PERF signals to be generated.
 
 Selection of the value for each counter is done via the config registers. There
 is one register for each counter. Counter 0 is special in that it always counts
-“time” and when expired causes a lock on itself and the other counters and an
+"time" and when expired causes a lock on itself and the other counters and an
 interrupt is raised. If any other counter overflows, it continues counting, and
 no interrupt is raised.
 
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 10/53] docs: admin-guide: pm: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (14 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Rafael J. Wysocki,
	Viresh Kumar, linux-kernel, linux-pm

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/admin-guide/pm/intel_idle.rst   | 4 ++--
 Documentation/admin-guide/pm/intel_pstate.rst | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst
index 89309e1b0e48..c3c4f5d4c806 100644
--- a/Documentation/admin-guide/pm/intel_idle.rst
+++ b/Documentation/admin-guide/pm/intel_idle.rst
@@ -28,7 +28,7 @@ logical CPU executing it is idle and so it may be possible to put some of the
 processor's functional blocks into low-power states.  That instruction takes two
 arguments (passed in the ``EAX`` and ``ECX`` registers of the target CPU), the
 first of which, referred to as a *hint*, can be used by the processor to
-determine what can be done (for details refer to Intel Software Developer’s
+determine what can be done (for details refer to Intel Software Developer's
 Manual [1]_).  Accordingly, ``intel_idle`` refuses to work with processors in
 which the support for the ``MWAIT`` instruction has been disabled (for example,
 via the platform firmware configuration menu) or which do not support that
@@ -261,7 +261,7 @@ restrict the range of permissible idle states to the ones with core-level only
 References
 ==========
 
-.. [1] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B*,
+.. [1] *Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2B*,
        https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-2b-manual.html
 
 .. [2] *Advanced Configuration and Power Interface (ACPI) Specification*,
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst
index df29b4f1f219..d881a32acb6d 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -26,7 +26,7 @@ than just an operating frequency or an operating performance point (see the
 LinuxCon Europe 2015 presentation by Kristen Accardi [1]_ for more
 information about that).  For this reason, the representation of P-states used
 by ``intel_pstate`` internally follows the hardware specification (for details
-refer to Intel Software Developer’s Manual [2]_).  However, the ``CPUFreq`` core
+refer to Intel Software Developer's Manual [2]_).  However, the ``CPUFreq`` core
 uses frequencies for identifying operating performance points of CPUs and
 frequencies are involved in the user space interface exposed by it, so
 ``intel_pstate`` maps its internal representation of P-states to frequencies too
@@ -756,7 +756,7 @@ References
 .. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*,
        https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf
 
-.. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*,
+.. [2] *Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3: System Programming Guide*,
        https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html
 
 .. [3] *Advanced Configuration and Power Interface Specification*,
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Leo Yan, Mathieu Poirier,
	Mike Leach, Suzuki K Poulose, coresight, linux-arm-kernel,
	linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../coresight/coresight-etm4x-reference.rst      | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
index b64d9a9c79df..e8ddfc144d9a 100644
--- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
+++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
@@ -15,14 +15,14 @@ Root: ``/sys/bus/coresight/devices/etm<N>``
 
 The following paragraphs explain the association between sysfs files and the
 ETMv4 registers that they effect. Note the register names are given without
-the ‘TRC’ prefix.
+the 'TRC' prefix.
 
 ----
 
 :File:            ``mode`` (rw)
 :Trace Registers: {CONFIGR + others}
 :Notes:
-    Bit select trace features. See ‘mode’ section below. Bits
+    Bit select trace features. See 'mode' section below. Bits
     in this will cause equivalent programming of trace config and
     other registers to enable the features requested.
 
@@ -89,7 +89,7 @@ the ‘TRC’ prefix.
 :Notes:
     Pair of addresses for a range selected by addr_idx. Include
     / exclude according to the optional parameter, or if omitted
-    uses the current ‘mode’ setting. Select comparator range in
+    uses the current 'mode' setting. Select comparator range in
     control register. Error if index is odd value.
 
 :Depends: ``mode, addr_idx``
@@ -277,7 +277,7 @@ the ‘TRC’ prefix.
 :Trace Registers: VICTLR{23:20}
 :Notes:
     Program non-secure exception level filters. Set / clear NS
-    exception filter bits. Setting ‘1’ excludes trace from the
+    exception filter bits. Setting '1' excludes trace from the
     exception level.
 
 :Syntax:
@@ -427,7 +427,7 @@ the ‘TRC’ prefix.
 :Syntax:
     ``echo idx > vmid_idx``
 
-    Where idx <  numvmidc
+    Where idx <  numvmidc
 
 ----
 
@@ -628,7 +628,7 @@ the reset parameter::
 
 
 
-The ‘mode’ sysfs parameter.
+The 'mode' sysfs parameter.
 ---------------------------
 
 This is a bitfield selection parameter that sets the overall trace mode for the
@@ -696,7 +696,7 @@ Bit assignments shown below:-
     ETM_MODE_QELEM(val)
 
 **description:**
-    ‘val’ determines level of Q element support enabled if
+    'val' determines level of Q element support enabled if
     implemented by the ETM [IDR0]
 
 
@@ -780,7 +780,7 @@ Bit assignments shown below:-
 ----
 
 *Note a)* On startup the ETM is programmed to trace the complete address space
-using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
+using address range comparator 0. 'mode' bits 30 / 31 modify this setting to
 set EL exclude bits for NS state in either user space (EL0) or kernel space
 (EL1) in the address range comparator. (the default setting excludes all
 secure EL, and NS EL2)
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Leo Yan, Mathieu Poirier,
	Mike Leach, Suzuki K Poulose, coresight, linux-arm-kernel,
	linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../coresight/coresight-etm4x-reference.rst      | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
index b64d9a9c79df..e8ddfc144d9a 100644
--- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
+++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
@@ -15,14 +15,14 @@ Root: ``/sys/bus/coresight/devices/etm<N>``
 
 The following paragraphs explain the association between sysfs files and the
 ETMv4 registers that they effect. Note the register names are given without
-the ‘TRC’ prefix.
+the 'TRC' prefix.
 
 ----
 
 :File:            ``mode`` (rw)
 :Trace Registers: {CONFIGR + others}
 :Notes:
-    Bit select trace features. See ‘mode’ section below. Bits
+    Bit select trace features. See 'mode' section below. Bits
     in this will cause equivalent programming of trace config and
     other registers to enable the features requested.
 
@@ -89,7 +89,7 @@ the ‘TRC’ prefix.
 :Notes:
     Pair of addresses for a range selected by addr_idx. Include
     / exclude according to the optional parameter, or if omitted
-    uses the current ‘mode’ setting. Select comparator range in
+    uses the current 'mode' setting. Select comparator range in
     control register. Error if index is odd value.
 
 :Depends: ``mode, addr_idx``
@@ -277,7 +277,7 @@ the ‘TRC’ prefix.
 :Trace Registers: VICTLR{23:20}
 :Notes:
     Program non-secure exception level filters. Set / clear NS
-    exception filter bits. Setting ‘1’ excludes trace from the
+    exception filter bits. Setting '1' excludes trace from the
     exception level.
 
 :Syntax:
@@ -427,7 +427,7 @@ the ‘TRC’ prefix.
 :Syntax:
     ``echo idx > vmid_idx``
 
-    Where idx <  numvmidc
+    Where idx <  numvmidc
 
 ----
 
@@ -628,7 +628,7 @@ the reset parameter::
 
 
 
-The ‘mode’ sysfs parameter.
+The 'mode' sysfs parameter.
 ---------------------------
 
 This is a bitfield selection parameter that sets the overall trace mode for the
@@ -696,7 +696,7 @@ Bit assignments shown below:-
     ETM_MODE_QELEM(val)
 
 **description:**
-    ‘val’ determines level of Q element support enabled if
+    'val' determines level of Q element support enabled if
     implemented by the ETM [IDR0]
 
 
@@ -780,7 +780,7 @@ Bit assignments shown below:-
 ----
 
 *Note a)* On startup the ETM is programmed to trace the complete address space
-using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
+using address range comparator 0. 'mode' bits 30 / 31 modify this setting to
 set EL exclude bits for NS state in either user space (EL0) or kernel space
 (EL1) in the address range comparator. (the default setting excludes all
 secure EL, and NS EL2)
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 12/53] docs: driver-api: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (16 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
       [not found]   ` <CAHp75Vegsb-+fVppv3C7Jp0a=mEGAh2pchX=Cr5ZvOMFt+G73Q@mail.gmail.com>
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Andy Shevchenko,
	Dan Williams, Dave Ertman, Drew Fustini, Greg Kroah-Hartman,
	Hans de Goede, Heikki Krogerus, Jacob Keller, Michael Walle,
	Philipp Zabel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/driver-api/index.rst | 2 +-
 Documentation/driver-api/ioctl.rst | 8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index f5a3207aa7fa..29eb9230b7a9 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces — it will hopefully get better over time!  The
+of some of those interfaces - it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/ioctl.rst b/Documentation/driver-api/ioctl.rst
index c455db0e1627..5b76e765827d 100644
--- a/Documentation/driver-api/ioctl.rst
+++ b/Documentation/driver-api/ioctl.rst
@@ -25,9 +25,9 @@ ioctl commands that follow modern conventions: ``_IO``, ``_IOR``,
 with the correct parameters:
 
 _IO/_IOR/_IOW/_IOWR
-   The macro name specifies how the argument will be used.  It may be a
+   The macro name specifies how the argument will be used.  It may be a
    pointer to data to be passed into the kernel (_IOW), out of the kernel
-   (_IOR), or both (_IOWR).  _IO can indicate either commands with no
+   (_IOR), or both (_IOWR).  _IO can indicate either commands with no
    argument or those passing an integer value instead of a pointer.
    It is recommended to only use _IO for commands without arguments,
    and use pointers for passing data.
@@ -200,10 +200,10 @@ cause an information leak, which can be used to defeat kernel address
 space layout randomization (KASLR), helping in an attack.
 
 For this reason (and for compat support) it is best to avoid any
-implicit padding in data structures.  Where there is implicit padding
+implicit padding in data structures.  Where there is implicit padding
 in an existing structure, kernel drivers must be careful to fully
 initialize an instance of the structure before copying it to user
-space.  This is usually done by calling memset() before assigning to
+space.  This is usually done by calling memset() before assigning to
 individual members.
 
 Subsystem abstractions
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 13/53] docs: driver-api: fpga: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (17 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 17:48   ` Moritz Fischer
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Moritz Fischer, Tom Rix,
	linux-fpga, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/driver-api/fpga/fpga-bridge.rst | 10 +++++-----
 Documentation/driver-api/fpga/fpga-mgr.rst    | 12 +++++------
 .../driver-api/fpga/fpga-programming.rst      |  8 ++++----
 Documentation/driver-api/fpga/fpga-region.rst | 20 +++++++++----------
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 198aadafd3e7..8d650b4e2ce6 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge — The FPGA Bridge structure
-* struct fpga_bridge_ops — Low level Bridge driver ops
-* devm_fpga_bridge_create() — Allocate and init a bridge struct
-* fpga_bridge_register() — Register a bridge
-* fpga_bridge_unregister() — Unregister a bridge
+* struct fpga_bridge - The FPGA Bridge structure
+* struct fpga_bridge_ops - Low level Bridge driver ops
+* devm_fpga_bridge_create() - Allocate and init a bridge struct
+* fpga_bridge_register() - Register a bridge
+* fpga_bridge_unregister() - Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 917ee22db429..4d926b452cb3 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` —  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager —  the FPGA manager struct
-* struct fpga_manager_ops —  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() —  Allocate and init a manager struct
-* fpga_mgr_register() —  Register an FPGA manager
-* fpga_mgr_unregister() —  Unregister an FPGA manager
+* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager -  the FPGA manager struct
+* struct fpga_manager_ops -  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() -  Allocate and init a manager struct
+* fpga_mgr_register() -  Register an FPGA manager
+* fpga_mgr_unregister() -  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index 002392dab04f..fb4da4240e96 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() —  Program an FPGA
-* fpga_image_info() —  Specifies what FPGA image to program
-* fpga_image_info_alloc() —  Allocate an FPGA image info struct
-* fpga_image_info_free() —  Free an FPGA image info struct
+* fpga_region_program_fpga() -  Program an FPGA
+* fpga_image_info() -  Specifies what FPGA image to program
+* fpga_image_info_alloc() -  Allocate an FPGA image info struct
+* fpga_image_info_free() -  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 363a8171ab0a..2636a27c11b2 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region — The FPGA region struct
-* devm_fpga_region_create() — Allocate and init a region struct
-* fpga_region_register() —  Register an FPGA region
-* fpga_region_unregister() —  Unregister an FPGA region
+* struct fpga_region - The FPGA region struct
+* devm_fpga_region_create() - Allocate and init a region struct
+* fpga_region_register() -  Register an FPGA region
+* fpga_region_unregister() -  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() —  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() — Put an FPGA manager
+* fpga_mgr_put() - Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() — Given a list of bridges, put them
+* fpga_bridges_put() - Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 14/53] docs: driver-api: iio: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (18 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, André Almeida, Jonathan Corbet,
	Greg Kroah-Hartman, Jonathan Cameron, Luca Ceresoli,
	Mike Rapoport, Randy Dunlap, Takashi Iwai, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/driver-api/iio/buffers.rst           |  8 ++++----
 Documentation/driver-api/iio/hw-consumer.rst       | 10 +++++-----
 Documentation/driver-api/iio/triggered-buffers.rst |  6 +++---
 Documentation/driver-api/iio/triggers.rst          | 10 +++++-----
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index e83026aebe97..24569ff0cf79 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer — general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel
+* struct iio_buffer - general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` — Grab a reference to the buffer
-* :c:func:`iio_buffer_put` — Release the reference to the buffer
+* :c:func:`iio_buffer_get` - Grab a reference to the buffer
+* :c:func:`iio_buffer_put` - Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 76133a3796f2..75986358fc02 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer — Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` — Disable IIO hardware consumer
+* struct iio_hw_consumer - Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 417555dbbdf4..7c37b2afa1ad 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` — Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops — buffer setup related callbacks
+* struct iio_buffer_setup_ops - buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index 288625e40672..a5d1fc15747c 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger — industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register
+* struct iio_trigger - industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` — Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops — operations structure for an iio_trigger.
+* struct iio_trigger_ops - operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 15/53] docs: driver-api: thermal: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (19 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Amit Daniel Kachhap,
	Daniel Lezcano, Lukasz Luba, Viresh Kumar, linux-kernel,
	linux-pm

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../driver-api/thermal/cpu-idle-cooling.rst        | 14 +++++++-------
 .../driver-api/thermal/intel_powerclamp.rst        |  6 +++---
 .../thermal/x86_pkg_temperature_thermal.rst        |  2 +-
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/driver-api/thermal/cpu-idle-cooling.rst b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
index c2a7ca676853..60934a518560 100644
--- a/Documentation/driver-api/thermal/cpu-idle-cooling.rst
+++ b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
@@ -49,7 +49,7 @@ belong to the same cluster, with a duration greater than the cluster
 idle state target residency, we lead to dropping the static and the
 dynamic leakage for this period (modulo the energy needed to enter
 this state). So the sustainable power with idle cycles has a linear
-relation with the OPP’s sustainable power and can be computed with a
+relation with the OPP's sustainable power and can be computed with a
 coefficient similar to::
 
 	    Power(IdleCycle) = Coef x Power(OPP)
@@ -134,7 +134,7 @@ The idle injection duration value must comply with the constraints:
   user experience, reactivity vs performance trade off we want. This
   value should be specified.
 
-- It is greater than the idle state’s target residency we want to go
+- It is greater than the idle state's target residency we want to go
   for thermal mitigation, otherwise we end up consuming more energy.
 
 Power considerations
@@ -146,11 +146,11 @@ power for a specific temperature but at this time we consume::
  Power = Capacitance x Voltage^2 x Frequency x Utilisation
 
 ... which is more than the sustainable power (or there is something
-wrong in the system setup). The ‘Capacitance’ and ‘Utilisation’ are a
-fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially
-because we don’t want to change the OPP. We can group the
-‘Capacitance’ and the ‘Utilisation’ into a single term which is the
-‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have::
+wrong in the system setup). The 'Capacitance' and 'Utilisation' are a
+fixed value, 'Voltage' and the 'Frequency' are fixed artificially
+because we don't want to change the OPP. We can group the
+'Capacitance' and the 'Utilisation' into a single term which is the
+'Dynamic Power Coefficient (Cdyn)' Simplifying the above, we have::
 
  Pdyn = Cdyn x Voltage^2 x Frequency
 
diff --git a/Documentation/driver-api/thermal/intel_powerclamp.rst b/Documentation/driver-api/thermal/intel_powerclamp.rst
index 3f6dfb0b3ea6..d349c1b64281 100644
--- a/Documentation/driver-api/thermal/intel_powerclamp.rst
+++ b/Documentation/driver-api/thermal/intel_powerclamp.rst
@@ -29,7 +29,7 @@ By:
 INTRODUCTION
 ============
 
-Consider the situation where a system’s power consumption must be
+Consider the situation where a system's power consumption must be
 reduced at runtime, due to power budget, thermal constraint, or noise
 level, and where active cooling is not preferred. Software managed
 passive power reduction must be performed to prevent the hardware
@@ -39,7 +39,7 @@ Currently, P-states, T-states (clock modulation), and CPU offlining
 are used for CPU throttling.
 
 On Intel CPUs, C-states provide effective power reduction, but so far
-they’re only used opportunistically, based on workload. With the
+they're only used opportunistically, based on workload. With the
 development of intel_powerclamp driver, the method of synchronizing
 idle injection across all online CPU threads was introduced. The goal
 is to achieve forced and controllable C-state residency.
@@ -264,7 +264,7 @@ CPUs).
 Usage and Interfaces
 ====================
 The powerclamp driver is registered to the generic thermal layer as a
-cooling device. Currently, it’s not bound to any thermal zones::
+cooling device. Currently, it's not bound to any thermal zones::
 
   jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
   cur_state:0
diff --git a/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst b/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
index 2ac42ccd236f..5b95af96e40f 100644
--- a/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
+++ b/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
@@ -13,7 +13,7 @@ Authors: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
 Reference
 ---------
 
-Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013):
+Intel® 64 and IA-32 Architectures Software Developer's Manual (Jan, 2013):
 Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT
 
 Description
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 16/53] docs: driver-api: media: drivers: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (20 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Daniel W. S. Almeida, Jonathan Corbet,
	Corentin Labbe, Mauro Carvalho Chehab, linux-kernel, linux-media,
	mjpeg-users

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00ad ('­'): SOFT HYPHEN
	- U+00b4 ('´'): ACUTE ACCENT
	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../driver-api/media/drivers/sh_mobile_ceu_camera.rst     | 8 ++++----
 Documentation/driver-api/media/drivers/vidtv.rst          | 4 ++--
 Documentation/driver-api/media/drivers/zoran.rst          | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst b/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst
index 822fcb8368ae..280a322c34c6 100644
--- a/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst
+++ b/Documentation/driver-api/media/drivers/sh_mobile_ceu_camera.rst
@@ -30,10 +30,10 @@ Generic scaling / cropping scheme
 	|                       `. .6--
 	|
 	|                        . .6'-
-	|                      .´
-	|           ... -4'- .´
-	|       ...´             - -7'.
-	+-5'- .´               -/
+	|                      .'
+	|           ... -4'- .'
+	|       ...'             - -7'.
+	+-5'- .'               -/
 	|            -- -3'- -/
 	|         --/
 	|      --/
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index 673bdff919ea..abb454302ac5 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology — Generic
-coding of moving pictures and associated audio information — Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology - Generic
+coding of moving pictures and associated audio information - Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst
index 83cbae9cedef..b205e10c3154 100644
--- a/Documentation/driver-api/media/drivers/zoran.rst
+++ b/Documentation/driver-api/media/drivers/zoran.rst
@@ -319,7 +319,7 @@ Conexant bt866 TV encoder
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 - is used in AVS6EYES, and
-- can generate: NTSC/PAL, PAL­M, PAL­N
+- can generate: NTSC/PAL, PAL-M, PAL-N
 
 The adv717x, should be able to produce PAL N. But you find nothing PAL N
 specific in the registers. Seem that you have to reuse a other standard
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 17/53] docs: driver-api: firmware: other_interfaces.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (21 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/driver-api/firmware/other_interfaces.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
index b81794e0cfbb..6711b3572408 100644
--- a/Documentation/driver-api/firmware/other_interfaces.rst
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -23,7 +23,7 @@ Exception Level 3 (EL3).
 
 The Intel Stratix10 SoC service layer provides an in kernel API for
 drivers to request access to the secure features. The requests are queued
-and processed one by one. ARM’s SMCCC is used to pass the execution
+and processed one by one. ARM's SMCCC is used to pass the execution
 of the requests on to a secure monitor (EL3).
 
 .. kernel-doc:: include/linux/firmware/intel/stratix10-svc-client.h
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 18/53] docs: driver-api: nvdimm: btt.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (22 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/driver-api/nvdimm/btt.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index 107395c042ae..dd91a495e02e 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block – has valid postmap
+	   1  1	  Normal Block - has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 19/53] docs: fault-injection: nvme-fault-injection.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (23 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Akinobu Mita, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/fault-injection/nvme-fault-injection.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/fault-injection/nvme-fault-injection.rst b/Documentation/fault-injection/nvme-fault-injection.rst
index 1d4427890d75..d372ce66a244 100644
--- a/Documentation/fault-injection/nvme-fault-injection.rst
+++ b/Documentation/fault-injection/nvme-fault-injection.rst
@@ -25,7 +25,7 @@ Example 1: Inject default status code with no retry
 
 Expected Result::
 
-  cp: cannot stat ‘/mnt/a.file’: Input/output error
+  cp: cannot stat '/mnt/a.file': Input/output error
 
 Message from dmesg::
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 20/53] docs: usb: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (24 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Alan Stern,
	Greg Kroah-Hartman, Johan Hovold, linux-kernel, linux-usb

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/usb/ehci.rst           |  2 +-
 Documentation/usb/gadget_printer.rst |  2 +-
 Documentation/usb/mass-storage.rst   | 36 ++++++++++++++--------------
 Documentation/usb/mtouchusb.rst      |  2 +-
 Documentation/usb/usb-serial.rst     |  2 +-
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/Documentation/usb/ehci.rst b/Documentation/usb/ehci.rst
index 31f650e7c1b4..76190501907a 100644
--- a/Documentation/usb/ehci.rst
+++ b/Documentation/usb/ehci.rst
@@ -1,4 +1,4 @@
-===========
+===========
 EHCI driver
 ===========
 
diff --git a/Documentation/usb/gadget_printer.rst b/Documentation/usb/gadget_printer.rst
index 5e5516c69075..e611a6d91093 100644
--- a/Documentation/usb/gadget_printer.rst
+++ b/Documentation/usb/gadget_printer.rst
@@ -1,4 +1,4 @@
-===============================
+===============================
 Linux USB Printer Gadget Driver
 ===============================
 
diff --git a/Documentation/usb/mass-storage.rst b/Documentation/usb/mass-storage.rst
index d181b47c3cb6..71dfd09b50a4 100644
--- a/Documentation/usb/mass-storage.rst
+++ b/Documentation/usb/mass-storage.rst
@@ -40,7 +40,7 @@ Module parameters
     This parameter lists paths to files or block devices used for
     backing storage for each logical unit.  There may be at most
     FSG_MAX_LUNS (8) LUNs set.  If more files are specified, they will
-    be silently ignored.  See also “luns” parameter.
+    be silently ignored.  See also "luns" parameter.
 
     *BEWARE* that if a file is used as a backing storage, it may not
     be modified by any other process.  This is because the host
@@ -56,18 +56,18 @@ Module parameters
   - removable=b[,b...]
 
     This parameter specifies whether each logical unit should be
-    removable.  “b” here is either “y”, “Y” or “1” for true or “n”,
-    “N” or “0” for false.
+    removable.  "b" here is either "y", "Y" or "1" for true or "n",
+    "N" or "0" for false.
 
     If this option is set for a logical unit, gadget will accept an
-    “eject” SCSI request (Start/Stop Unit).  When it is sent, the
+    "eject" SCSI request (Start/Stop Unit).  When it is sent, the
     backing file will be closed to simulate ejection and the logical
     unit will not be mountable by the host until a new backing file is
-    specified by userspace on the device (see “sysfs entries”
+    specified by userspace on the device (see "sysfs entries"
     section).
 
     If a logical unit is not removable (the default), a backing file
-    must be specified for it with the “file” parameter as the module
+    must be specified for it with the "file" parameter as the module
     is loaded.  The same applies if the module is built in, no
     exceptions.
 
@@ -76,13 +76,13 @@ Module parameters
     and because it seems like a saner default after all.  Thus to
     maintain compatibility with older kernels, it's best to specify
     the default values.  Also, if one relied on old default, explicit
-    “n” needs to be specified now.
+    "n" needs to be specified now.
 
-    Note that “removable” means the logical unit's media can be
+    Note that "removable" means the logical unit's media can be
     ejected or removed (as is true for a CD-ROM drive or a card
     reader).  It does *not* mean that the entire gadget can be
     unplugged from the host; the proper term for that is
-    “hot-unpluggable”.
+    "hot-unpluggable".
 
   - cdrom=b[,b...]
 
@@ -107,7 +107,7 @@ Module parameters
     This parameter specifies whether FUA flag should be ignored in SCSI
     Write10 and Write12 commands sent to given logical units.
 
-    MS Windows mounts removable storage in “Removal optimised mode” by
+    MS Windows mounts removable storage in "Removal optimised mode" by
     default.  All the writes to the media are synchronous, which is
     achieved by setting the FUA (Force Unit Access) bit in SCSI
     Write(10,12) commands.  This forces each write to wait until the
@@ -127,11 +127,11 @@ Module parameters
     capped.
 
     If this parameter is provided, and the number of files specified
-    in “file” argument is greater then the value of “luns”, all excess
+    in "file" argument is greater then the value of "luns", all excess
     files will be ignored.
 
     If this parameter is not present, the number of logical units will
-    be deduced from the number of files specified in the “file”
+    be deduced from the number of files specified in the "file"
     parameter.  If the file parameter is missing as well, one is
     assumed.
 
@@ -217,18 +217,18 @@ Relation to file storage gadget
   All users need to transition to the Mass Storage Gadget.  The two
   gadgets behave mostly the same from the outside except:
 
-  1. In FSG the “removable” and “cdrom” module parameters set the flag
+  1. In FSG the "removable" and "cdrom" module parameters set the flag
      for all logical units whereas in MSG they accept a list of y/n
      values for each logical unit.  If one uses only a single logical
      unit this does not matter, but if there are more, the y/n value
      needs to be repeated for each logical unit.
 
-  2. FSG's “serial”, “vendor”, “product” and “release” module
+  2. FSG's "serial", "vendor", "product" and "release" module
      parameters are handled in MSG by the composite layer's parameters
-     named respectively: “iSerialnumber”, “idVendor”, “idProduct” and
-     “bcdDevice”.
+     named respectively: "iSerialnumber", "idVendor", "idProduct" and
+     "bcdDevice".
 
-  3. MSG does not support FSG's test mode, thus “transport”,
-     “protocol” and “buflen” FSG's module parameters are not
+  3. MSG does not support FSG's test mode, thus "transport",
+     "protocol" and "buflen" FSG's module parameters are not
      supported.  MSG always uses SCSI protocol with bulk only
      transport mode and 16 KiB buffers.
diff --git a/Documentation/usb/mtouchusb.rst b/Documentation/usb/mtouchusb.rst
index d1111b74bf75..5ae1f74fe74b 100644
--- a/Documentation/usb/mtouchusb.rst
+++ b/Documentation/usb/mtouchusb.rst
@@ -1,4 +1,4 @@
-================
+================
 mtouchusb driver
 ================
 
diff --git a/Documentation/usb/usb-serial.rst b/Documentation/usb/usb-serial.rst
index 8fa7dbd3da9a..69586aeb60bb 100644
--- a/Documentation/usb/usb-serial.rst
+++ b/Documentation/usb/usb-serial.rst
@@ -1,4 +1,4 @@
-==========
+==========
 USB serial
 ==========
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 21/53] docs: process: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (25 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Greg Kroah-Hartman, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/process/code-of-conduct.rst              | 2 +-
 Documentation/process/kernel-enforcement-statement.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index be50294aebd5..2060834b9cee 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -32,7 +32,7 @@ Examples of unacceptable behavior by participants include:
   advances
 * Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing others’ private information, such as a physical or electronic
+* Publishing others' private information, such as a physical or electronic
   address, without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting
diff --git a/Documentation/process/kernel-enforcement-statement.rst b/Documentation/process/kernel-enforcement-statement.rst
index e5a1be476047..dc2d813b2e79 100644
--- a/Documentation/process/kernel-enforcement-statement.rst
+++ b/Documentation/process/kernel-enforcement-statement.rst
@@ -1,4 +1,4 @@
-.. _process_statement_kernel:
+.. _process_statement_kernel:
 
 Linux Kernel Enforcement Statement
 ----------------------------------
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 22/53] docs: block: data-integrity.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (26 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/block/data-integrity.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst
index 4f2452a95c43..07a97aa26668 100644
--- a/Documentation/block/data-integrity.rst
+++ b/Documentation/block/data-integrity.rst
@@ -1,4 +1,4 @@
-==============
+==============
 Data Integrity
 ==============
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 23/53] docs: userspace-api: media: fdl-appendix.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (27 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Mauro Carvalho Chehab,
	linux-kernel, linux-media

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../userspace-api/media/fdl-appendix.rst      | 64 +++++++++----------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/Documentation/userspace-api/media/fdl-appendix.rst b/Documentation/userspace-api/media/fdl-appendix.rst
index 683ebed87017..b1bc725b4ec7 100644
--- a/Documentation/userspace-api/media/fdl-appendix.rst
+++ b/Documentation/userspace-api/media/fdl-appendix.rst
@@ -13,14 +13,14 @@ GNU Free Documentation License
 ===========
 
 The purpose of this License is to make a manual, textbook, or other
-written document “free” in the sense of freedom: to assure everyone the
+written document "free" in the sense of freedom: to assure everyone the
 effective freedom to copy and redistribute it, with or without modifying
 it, either commercially or noncommercially. Secondarily, this License
 preserves for the author and publisher a way to get credit for their
 work, while not being considered responsible for modifications made by
 others.
 
-This License is a kind of “copyleft”, which means that derivative works
+This License is a kind of "copyleft", which means that derivative works
 of the document must themselves be free in the same sense. It
 complements the GNU General Public License, which is a copyleft license
 designed for free software.
@@ -44,21 +44,21 @@ works whose purpose is instruction or reference.
 
 This License applies to any manual or other work that contains a notice
 placed by the copyright holder saying it can be distributed under the
-terms of this License. The “Document”, below, refers to any such manual
+terms of this License. The "Document", below, refers to any such manual
 or work. Any member of the public is a licensee, and is addressed as
-“you”.
+"you".
 
 
 .. _fdl-modified:
 
-A “Modified Version” of the Document means any work containing the
+A "Modified Version" of the Document means any work containing the
 Document or a portion of it, either copied verbatim, or with
 modifications and/or translated into another language.
 
 
 .. _fdl-secondary:
 
-A “Secondary Section” is a named appendix or a front-matter section of
+A "Secondary Section" is a named appendix or a front-matter section of
 the :ref:`Document <fdl-document>` that deals exclusively with the
 relationship of the publishers or authors of the Document to the
 Document's overall subject (or to related matters) and contains nothing
@@ -72,7 +72,7 @@ regarding them.
 
 .. _fdl-invariant:
 
-The “Invariant Sections” are certain
+The "Invariant Sections" are certain
 :ref:`Secondary Sections <fdl-secondary>` whose titles are designated,
 as being those of Invariant Sections, in the notice that says that the
 :ref:`Document <fdl-document>` is released under this License.
@@ -80,14 +80,14 @@ as being those of Invariant Sections, in the notice that says that the
 
 .. _fdl-cover-texts:
 
-The “Cover Texts” are certain short passages of text that are listed, as
+The "Cover Texts" are certain short passages of text that are listed, as
 Front-Cover Texts or Back-Cover Texts, in the notice that says that the
 :ref:`Document <fdl-document>` is released under this License.
 
 
 .. _fdl-transparent:
 
-A “Transparent” copy of the :ref:`Document <fdl-document>` means a
+A "Transparent" copy of the :ref:`Document <fdl-document>` means a
 machine-readable copy, represented in a format whose specification is
 available to the general public, whose contents can be viewed and edited
 directly and straightforwardly with generic text editors or (for images
@@ -97,7 +97,7 @@ formatters or for automatic translation to a variety of formats suitable
 for input to text formatters. A copy made in an otherwise Transparent
 file format whose markup has been designed to thwart or discourage
 subsequent modification by readers is not Transparent. A copy that is
-not “Transparent” is called “Opaque”.
+not "Transparent" is called "Opaque".
 
 Examples of suitable formats for Transparent copies include plain ASCII
 without markup, Texinfo input format, LaTeX input format, SGML or XML
@@ -111,10 +111,10 @@ word processors for output purposes only.
 
 .. _fdl-title-page:
 
-The “Title Page” means, for a printed book, the title page itself, plus
+The "Title Page" means, for a printed book, the title page itself, plus
 such following pages as are needed to hold, legibly, the material this
 License requires to appear in the title page. For works in formats which
-do not have any title page as such, “Title Page” means the text near the
+do not have any title page as such, "Title Page" means the text near the
 most prominent appearance of the work's title, preceding the beginning
 of the body of the text.
 
@@ -242,11 +242,11 @@ Modified Version:
    Include an unaltered copy of this License.
 
 -  **I.**
-   Preserve the section entitled “History”, and its title, and add to it
+   Preserve the section entitled "History", and its title, and add to it
    an item stating at least the title, year, new authors, and publisher
    of the :ref:`Modified Version <fdl-modified>` as given on the
    :ref:`Title Page <fdl-title-page>`. If there is no section entitled
-   “History” in the :ref:`Document <fdl-document>`, create one stating
+   "History" in the :ref:`Document <fdl-document>`, create one stating
    the title, year, authors, and publisher of the Document as given on
    its Title Page, then add an item describing the Modified Version as
    stated in the previous sentence.
@@ -256,13 +256,13 @@ Modified Version:
    :ref:`Document <fdl-document>` for public access to a
    :ref:`Transparent <fdl-transparent>` copy of the Document, and
    likewise the network locations given in the Document for previous
-   versions it was based on. These may be placed in the “History”
+   versions it was based on. These may be placed in the "History"
    section. You may omit a network location for a work that was
    published at least four years before the Document itself, or if the
    original publisher of the version it refers to gives permission.
 
 -  **K.**
-   In any section entitled “Acknowledgements” or “Dedications”, preserve
+   In any section entitled "Acknowledgements" or "Dedications", preserve
    the section's title, and preserve in the section all the substance
    and tone of each of the contributor acknowledgements and/or
    dedications given therein.
@@ -274,11 +274,11 @@ Modified Version:
    part of the section titles.
 
 -  **M.**
-   Delete any section entitled “Endorsements”. Such a section may not be
+   Delete any section entitled "Endorsements". Such a section may not be
    included in the :ref:`Modified Version <fdl-modified>`.
 
 -  **N.**
-   Do not retitle any existing section as “Endorsements” or to conflict
+   Do not retitle any existing section as "Endorsements" or to conflict
    in title with any :ref:`Invariant Section <fdl-invariant>`.
 
 If the :ref:`Modified Version <fdl-modified>` includes new
@@ -290,7 +290,7 @@ of :ref:`Invariant Sections <fdl-invariant>` in the Modified Version's
 license notice. These titles must be distinct from any other section
 titles.
 
-You may add a section entitled “Endorsements”, provided it contains
+You may add a section entitled "Endorsements", provided it contains
 nothing but endorsements of your
 :ref:`Modified Version <fdl-modified>` by various parties--for
 example, statements of peer review or that the text has been approved by
@@ -337,11 +337,11 @@ the original author or publisher of that section if known, or else a
 unique number. Make the same adjustment to the section titles in the
 list of Invariant Sections in the license notice of the combined work.
 
-In the combination, you must combine any sections entitled “History” in
-the various original documents, forming one section entitled “History”;
-likewise combine any sections entitled “Acknowledgements”, and any
-sections entitled “Dedications”. You must delete all sections entitled
-“Endorsements.”
+In the combination, you must combine any sections entitled "History" in
+the various original documents, forming one section entitled "History";
+likewise combine any sections entitled "Acknowledgements", and any
+sections entitled "Dedications". You must delete all sections entitled
+"Endorsements."
 
 
 .. _fdl-section6:
@@ -372,7 +372,7 @@ with other separate and independent documents or works, in or on a
 volume of a storage or distribution medium, does not as a whole count as
 a :ref:`Modified Version <fdl-modified>` of the Document, provided no
 compilation copyright is claimed for the compilation. Such a compilation
-is called an “aggregate”, and this License does not apply to the other
+is called an "aggregate", and this License does not apply to the other
 self-contained works thus compiled with the Document , on account of
 their being thus compiled, if they are not themselves derivative works
 of the Document. If the :ref:`Cover Text <fdl-cover-texts>`
@@ -429,7 +429,7 @@ concerns. See
 
 Each version of the License is given a distinguishing version number. If
 the :ref:`Document <fdl-document>` specifies that a particular
-numbered version of this License “or any later version” applies to it,
+numbered version of this License "or any later version" applies to it,
 you have the option of following the terms and conditions either of that
 specified version or of any later version that has been published (not
 as a draft) by the Free Software Foundation. If the Document does not
@@ -455,13 +455,13 @@ notices just after the title page:
     being LIST THEIR TITLES, with the
     :ref:`Front-Cover Texts <fdl-cover-texts>` being LIST, and with
     the :ref:`Back-Cover Texts <fdl-cover-texts>` being LIST. A copy
-    of the license is included in the section entitled “GNU Free
-    Documentation License”.
+    of the license is included in the section entitled "GNU Free
+    Documentation License".
 
-If you have no :ref:`Invariant Sections <fdl-invariant>`, write “with
-no Invariant Sections” instead of saying which ones are invariant. If
-you have no :ref:`Front-Cover Texts <fdl-cover-texts>`, write “no
-Front-Cover Texts” instead of “Front-Cover Texts being LIST”; likewise
+If you have no :ref:`Invariant Sections <fdl-invariant>`, write "with
+no Invariant Sections" instead of saying which ones are invariant. If
+you have no :ref:`Front-Cover Texts <fdl-cover-texts>`, write "no
+Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise
 for :ref:`Back-Cover Texts <fdl-cover-texts>`.
 
 If your document contains nontrivial examples of program code, we
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 24/53] docs: userspace-api: media: v4l: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (28 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Hans Verkuil,
	Mauro Carvalho Chehab, Michael Tretter, Sakari Ailus,
	Stanimir Varbanov, Tomasz Figa, linux-kernel, linux-media

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2014 ('—'): EM DASH
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/userspace-api/media/v4l/biblio.rst |  8 ++++----
 Documentation/userspace-api/media/v4l/crop.rst   | 16 ++++++++--------
 .../userspace-api/media/v4l/dev-decoder.rst      |  6 +++---
 .../userspace-api/media/v4l/diff-v4l.rst         |  2 +-
 Documentation/userspace-api/media/v4l/open.rst   |  2 +-
 .../userspace-api/media/v4l/vidioc-cropcap.rst   |  4 ++--
 6 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 64d241daf63c..6e07b78bd39d 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology — Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology — Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology — Digital Compression and Coding of Continous-Tone Still Images — Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography — Digital still cameras — Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/userspace-api/media/v4l/crop.rst b/Documentation/userspace-api/media/v4l/crop.rst
index 3fe185e25ccf..23c2b71f449e 100644
--- a/Documentation/userspace-api/media/v4l/crop.rst
+++ b/Documentation/userspace-api/media/v4l/crop.rst
@@ -130,22 +130,22 @@ the driver state and therefore only adjust the requested rectangle.
 
 Suppose scaling on a video capture device is restricted to a factor 1:1
 or 2:1 in either direction and the target image size must be a multiple
-of 16 × 16 pixels. The source cropping rectangle is set to defaults,
-which are also the upper limit in this example, of 640 × 400 pixels at
-offset 0, 0. An application requests an image size of 300 × 225 pixels,
+of 16 x 16 pixels. The source cropping rectangle is set to defaults,
+which are also the upper limit in this example, of 640 x 400 pixels at
+offset 0, 0. An application requests an image size of 300 x 225 pixels,
 assuming video will be scaled down from the "full picture" accordingly.
-The driver sets the image size to the closest possible values 304 × 224,
+The driver sets the image size to the closest possible values 304 x 224,
 then chooses the cropping rectangle closest to the requested size, that
-is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
+is 608 x 224 (224 x 2:1 would exceed the limit 400). The offset 0, 0 is
 still valid, thus unmodified. Given the default cropping rectangle
 reported by :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>` the application can
 easily propose another offset to center the cropping rectangle.
 
 Now the application may insist on covering an area using a picture
 aspect ratio closer to the original request, so it asks for a cropping
-rectangle of 608 × 456 pixels. The present scaling factors limit
-cropping to 640 × 384, so the driver returns the cropping size 608 × 384
-and adjusts the image size to closest possible 304 × 192.
+rectangle of 608 x 456 pixels. The present scaling factors limit
+cropping to 640 x 384, so the driver returns the cropping size 608 x 384
+and adjusts the image size to closest possible 304 x 192.
 
 
 Examples
diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst
index 3d4138a4ba69..5b9b83feeceb 100644
--- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
@@ -38,7 +38,7 @@ Conventions and Notations Used in This Document
 6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
    [0..2]: i = 0, 1, 2.
 
-7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE``
+7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE``
    queue containing data that resulted from processing buffer A.
 
 .. _decoder-glossary:
@@ -288,7 +288,7 @@ Initialization
 
       Changing the ``OUTPUT`` format may change the currently set ``CAPTURE``
       format. How the new ``CAPTURE`` format is determined is up to the decoder
-      and the client must ensure it matches its needs afterwards.
+      and the client must ensure it matches its needs afterwards.
 
 2.  Allocate source (bytestream) buffers via :c:func:`VIDIOC_REQBUFS` on
     ``OUTPUT``.
@@ -874,7 +874,7 @@ it may be affected as per normal decoder operation.
 
    any of the following results on the ``CAPTURE`` queue is allowed:
 
-     {A’, B’, G’, H’}, {A’, G’, H’}, {G’, H’}.
+     {A', B', G', H'}, {A', G', H'}, {G', H'}.
 
    To determine the CAPTURE buffer containing the first decoded frame after the
    seek, the client may observe the timestamps to match the CAPTURE and OUTPUT
diff --git a/Documentation/userspace-api/media/v4l/diff-v4l.rst b/Documentation/userspace-api/media/v4l/diff-v4l.rst
index 33243ecb5033..9ce60e625974 100644
--- a/Documentation/userspace-api/media/v4l/diff-v4l.rst
+++ b/Documentation/userspace-api/media/v4l/diff-v4l.rst
@@ -447,7 +447,7 @@ name ``V4L2_FBUF_FLAG_CHROMAKEY``.
 
 In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
 to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
-size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
+size bitmap of 1024 x 625 bits. Struct :c:type:`v4l2_window`
 has a separate ``bitmap`` pointer field for this purpose and the bitmap
 size is determined by ``w.width`` and ``w.height``.
 
diff --git a/Documentation/userspace-api/media/v4l/open.rst b/Documentation/userspace-api/media/v4l/open.rst
index 18bfb9b8137d..b015bbbdf8b5 100644
--- a/Documentation/userspace-api/media/v4l/open.rst
+++ b/Documentation/userspace-api/media/v4l/open.rst
@@ -100,7 +100,7 @@ Where ``X`` is a non-negative integer.
 	$ tree /dev/v4l
 	/dev/v4l
 	├── by-id
-	│   └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0
+	│   └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0
 	└── by-path
 	    └── pci-0000:00:14.0-usb-0:2:1.0-video-index0 -> ../../video0
 
diff --git a/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst b/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst
index 551ac9d3c6ef..4ea652e66401 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst
@@ -69,8 +69,8 @@ overlay devices.
     * - struct :ref:`v4l2_rect <v4l2-rect-crop>`
       - ``defrect``
       - Default cropping rectangle, it shall cover the "whole picture".
-	Assuming pixel aspect 1/1 this could be for example a 640 × 480
-	rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM
+	Assuming pixel aspect 1/1 this could be for example a 640 x 480
+	rectangle for NTSC, a 768 x 576 rectangle for PAL and SECAM
 	centered over the active picture area. The same co-ordinate system
 	as for ``bounds`` is used.
     * - struct :c:type:`v4l2_fract`
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 25/53] docs: userspace-api: media: dvb: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (29 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Mauro Carvalho Chehab,
	Randy Dunlap, linux-kernel, linux-media

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../userspace-api/media/dvb/audio-set-bypass-mode.rst       | 2 +-
 Documentation/userspace-api/media/dvb/audio.rst             | 2 +-
 Documentation/userspace-api/media/dvb/dmx-fopen.rst         | 2 +-
 Documentation/userspace-api/media/dvb/dmx-fread.rst         | 2 +-
 Documentation/userspace-api/media/dvb/dmx-set-filter.rst    | 2 +-
 Documentation/userspace-api/media/dvb/intro.rst             | 6 +++---
 Documentation/userspace-api/media/dvb/video.rst             | 2 +-
 7 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst b/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst
index ecac02f1b2fc..80d551a2053a 100644
--- a/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst
+++ b/Documentation/userspace-api/media/dvb/audio-set-bypass-mode.rst
@@ -50,7 +50,7 @@ Description
 
 This ioctl call asks the Audio Device to bypass the Audio decoder and
 forward the stream without decoding. This mode shall be used if streams
-that can’t be handled by the Digital TV system shall be decoded. Dolby
+that can't be handled by the Digital TV system shall be decoded. Dolby
 DigitalTM streams are automatically forwarded by the Digital TV subsystem if
 the hardware can handle it.
 
diff --git a/Documentation/userspace-api/media/dvb/audio.rst b/Documentation/userspace-api/media/dvb/audio.rst
index eaae5675a47d..aa753336b31f 100644
--- a/Documentation/userspace-api/media/dvb/audio.rst
+++ b/Documentation/userspace-api/media/dvb/audio.rst
@@ -11,7 +11,7 @@ TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data
 types and ioctl definitions can be accessed by including
 ``linux/dvb/audio.h`` in your application.
 
-Please note that some Digital TV cards don’t have their own MPEG decoder, which
+Please note that some Digital TV cards don't have their own MPEG decoder, which
 results in the omission of the audio and video device.
 
 These ioctls were also used by V4L2 to control MPEG decoders implemented
diff --git a/Documentation/userspace-api/media/dvb/dmx-fopen.rst b/Documentation/userspace-api/media/dvb/dmx-fopen.rst
index 8f0a2b831d4a..50b36eb4371e 100644
--- a/Documentation/userspace-api/media/dvb/dmx-fopen.rst
+++ b/Documentation/userspace-api/media/dvb/dmx-fopen.rst
@@ -82,7 +82,7 @@ appropriately.
     :widths: 1 16
 
     -  -  ``EMFILE``
-       -  “Too many open files”, i.e. no more filters available.
+       -  "Too many open files", i.e. no more filters available.
 
 The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
diff --git a/Documentation/userspace-api/media/dvb/dmx-fread.rst b/Documentation/userspace-api/media/dvb/dmx-fread.rst
index 78e9daef595a..88c4cddf7c30 100644
--- a/Documentation/userspace-api/media/dvb/dmx-fread.rst
+++ b/Documentation/userspace-api/media/dvb/dmx-fread.rst
@@ -34,7 +34,7 @@ Description
 
 This system call returns filtered data, which might be section or Packetized
 Elementary Stream (PES) data. The filtered data is transferred from
-the driver’s internal circular buffer to ``buf``. The maximum amount of data
+the driver's internal circular buffer to ``buf``. The maximum amount of data
 to be transferred is implied by count.
 
 .. note::
diff --git a/Documentation/userspace-api/media/dvb/dmx-set-filter.rst b/Documentation/userspace-api/media/dvb/dmx-set-filter.rst
index f43455b7adae..1b8c8071b14f 100644
--- a/Documentation/userspace-api/media/dvb/dmx-set-filter.rst
+++ b/Documentation/userspace-api/media/dvb/dmx-set-filter.rst
@@ -37,7 +37,7 @@ parameters provided. A timeout may be defined stating number of seconds
 to wait for a section to be loaded. A value of 0 means that no timeout
 should be applied. Finally there is a flag field where it is possible to
 state whether a section should be CRC-checked, whether the filter should
-be a ”one-shot” filter, i.e. if the filtering operation should be
+be a "one-shot" filter, i.e. if the filtering operation should be
 stopped after the first section is received, and whether the filtering
 operation should be started immediately (without waiting for a
 :ref:`DMX_START` ioctl call). If a filter was previously set-up, this
diff --git a/Documentation/userspace-api/media/dvb/intro.rst b/Documentation/userspace-api/media/dvb/intro.rst
index a935f3914e56..6784ae79657c 100644
--- a/Documentation/userspace-api/media/dvb/intro.rst
+++ b/Documentation/userspace-api/media/dvb/intro.rst
@@ -107,7 +107,7 @@ Audio and video decoder
       a Systems on a Chip (SoC) integrated circuit.
 
       It may also not be needed for certain usages (e.g. for data-only
-      uses like “internet over satellite”).
+      uses like "internet over satellite").
 
 :ref:`stb_components` shows a crude schematic of the control and data
 flow between those components.
@@ -148,9 +148,9 @@ individual devices are called:
 
 -  ``/dev/dvb/adapterN/caM``,
 
-where ``N`` enumerates the Digital TV cards in a system starting from 0, and
+where ``N`` enumerates the Digital TV cards in a system starting from 0, and
 ``M`` enumerates the devices of each type within each adapter, starting
-from 0, too. We will omit the “``/dev/dvb/adapterN/``\ ” in the further
+from 0, too. We will omit the "``/dev/dvb/adapterN/``\ " in the further
 discussion of these devices.
 
 More details about the data structures and function calls of all the
diff --git a/Documentation/userspace-api/media/dvb/video.rst b/Documentation/userspace-api/media/dvb/video.rst
index 38a8d39a1d25..808705b769a1 100644
--- a/Documentation/userspace-api/media/dvb/video.rst
+++ b/Documentation/userspace-api/media/dvb/video.rst
@@ -16,7 +16,7 @@ stream, not its presentation on the TV or computer screen. On PCs this
 is typically handled by an associated video4linux device, e.g.
 **/dev/video**, which allows scaling and defining output windows.
 
-Some Digital TV cards don’t have their own MPEG decoder, which results in the
+Some Digital TV cards don't have their own MPEG decoder, which results in the
 omission of the audio and video device as well as the video4linux
 device.
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 26/53] docs: vm: zswap.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (30 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Sedat Dilek, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/vm/zswap.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/vm/zswap.rst b/Documentation/vm/zswap.rst
index d8d9fa4a1f0d..8edb8d578caf 100644
--- a/Documentation/vm/zswap.rst
+++ b/Documentation/vm/zswap.rst
@@ -10,7 +10,7 @@ Overview
 Zswap is a lightweight compressed cache for swap pages. It takes pages that are
 in the process of being swapped out and attempts to compress them into a
 dynamically allocated RAM-based memory pool.  zswap basically trades CPU cycles
-for potentially reduced swap I/O.  This trade-off can also result in a
+for potentially reduced swap I/O.  This trade-off can also result in a
 significant performance improvement if reads from the compressed cache are
 faster than reads from a swap device.
 
@@ -26,7 +26,7 @@ faster than reads from a swap device.
   performance impact of swapping.
 * Overcommitted guests that share a common I/O resource can
   dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
-  throttling by the hypervisor. This allows more work to get done with less
+  throttling by the hypervisor. This allows more work to get done with less
   impact to the guest workload and guests sharing the I/O subsystem
 * Users with SSDs as swap devices can extend the life of the device by
   drastically reducing life-shortening writes.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 27/53] docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Chao Yu, Jaegeuk Kim,
	linux-f2fs-devel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/filesystems/f2fs.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 992bf91eeec8..19d2cf477fc3 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26–52.
+10, 1, 26-52.
 
 Wandering Tree Problem
 ----------------------
@@ -86,8 +86,8 @@ Flash Awareness
 
 Wandering Tree Problem
 ----------------------
-- Use a term, “node”, that represents inodes as well as various pointer blocks
-- Introduce Node Address Table (NAT) containing the locations of all the “node”
+- Use a term, "node", that represents inodes as well as various pointer blocks
+- Introduce Node Address Table (NAT) containing the locations of all the "node"
   blocks; this will cut off the update propagation.
 
 Cleaning Overhead
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [f2fs-dev] [PATCH 27/53] docs: filesystems: f2fs.rst: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Jonathan Corbet, Mauro Carvalho Chehab, linux-kernel,
	linux-f2fs-devel, Jaegeuk Kim

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/filesystems/f2fs.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 992bf91eeec8..19d2cf477fc3 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26–52.
+10, 1, 26-52.
 
 Wandering Tree Problem
 ----------------------
@@ -86,8 +86,8 @@ Flash Awareness
 
 Wandering Tree Problem
 ----------------------
-- Use a term, “node”, that represents inodes as well as various pointer blocks
-- Introduce Node Address Table (NAT) containing the locations of all the “node”
+- Use a term, "node", that represents inodes as well as various pointer blocks
+- Introduce Node Address Table (NAT) containing the locations of all the "node"
   blocks; this will cut off the update propagation.
 
 Cleaning Overhead
-- 
2.30.2



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 28/53] docs: filesystems: ext4: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (32 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 19:23   ` Theodore Ts'o
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Theodore Ts'o,
	Andreas Dilger, linux-ext4, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
	- U+2217 ('∗'): ASTERISK OPERATOR

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/filesystems/ext4/attributes.rst | 20 +++++++++----------
 Documentation/filesystems/ext4/bigalloc.rst   |  6 +++---
 Documentation/filesystems/ext4/blockgroup.rst |  8 ++++----
 Documentation/filesystems/ext4/blocks.rst     |  2 +-
 Documentation/filesystems/ext4/directory.rst  | 16 +++++++--------
 Documentation/filesystems/ext4/eainode.rst    |  2 +-
 Documentation/filesystems/ext4/inlinedata.rst |  6 +++---
 Documentation/filesystems/ext4/inodes.rst     |  6 +++---
 Documentation/filesystems/ext4/journal.rst    |  8 ++++----
 Documentation/filesystems/ext4/mmp.rst        |  2 +-
 .../filesystems/ext4/special_inodes.rst       |  4 ++--
 Documentation/filesystems/ext4/super.rst      | 10 +++++-----
 12 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/Documentation/filesystems/ext4/attributes.rst b/Documentation/filesystems/ext4/attributes.rst
index 54386a010a8d..39e695678c01 100644
--- a/Documentation/filesystems/ext4/attributes.rst
+++ b/Documentation/filesystems/ext4/attributes.rst
@@ -8,7 +8,7 @@ block on the disk and referenced from inodes via ``inode.i_file_acl*``.
 The first use of extended attributes seems to have been for storing file
 ACLs and other security data (selinux). With the ``user_xattr`` mount
 option it is possible for users to store extended attributes so long as
-all attribute names begin with “user”; this restriction seems to have
+all attribute names begin with "user"; this restriction seems to have
 disappeared as of Linux 3.0.
 
 There are two places where extended attributes can be found. The first
@@ -165,22 +165,22 @@ the key name. Here is a map of name index values to key prefixes:
    * - 0
      - (no prefix)
    * - 1
-     - “user.”
+     - "user."
    * - 2
-     - “system.posix\_acl\_access”
+     - "system.posix\_acl\_access"
    * - 3
-     - “system.posix\_acl\_default”
+     - "system.posix\_acl\_default"
    * - 4
-     - “trusted.”
+     - "trusted."
    * - 6
-     - “security.”
+     - "security."
    * - 7
-     - “system.” (inline\_data only?)
+     - "system." (inline\_data only?)
    * - 8
-     - “system.richacl” (SuSE kernels only?)
+     - "system.richacl" (SuSE kernels only?)
 
-For example, if the attribute key is “user.fubar”, the attribute name
-index is set to 1 and the “fubar” name is recorded on disk.
+For example, if the attribute key is "user.fubar", the attribute name
+index is set to 1 and the "fubar" name is recorded on disk.
 
 POSIX ACLs
 ~~~~~~~~~~
diff --git a/Documentation/filesystems/ext4/bigalloc.rst b/Documentation/filesystems/ext4/bigalloc.rst
index 72075aa608e4..897e1b284c97 100644
--- a/Documentation/filesystems/ext4/bigalloc.rst
+++ b/Documentation/filesystems/ext4/bigalloc.rst
@@ -27,8 +27,8 @@ stored in the s\_log\_cluster\_size field in the superblock); from then
 on, the block bitmaps track clusters, not individual blocks. This means
 that block groups can be several gigabytes in size (instead of just
 128MiB); however, the minimum allocation unit becomes a cluster, not a
-block, even for directories. TaoBao had a patchset to extend the “use
-units of clusters instead of blocks” to the extent tree, though it is
+block, even for directories. TaoBao had a patchset to extend the "use
+units of clusters instead of blocks" to the extent tree, though it is
 not clear where those patches went-- they eventually morphed into
-“extent tree v2” but that code has not landed as of May 2015.
+"extent tree v2" but that code has not landed as of May 2015.
 
diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst
index 3da156633339..99aa1f330bd1 100644
--- a/Documentation/filesystems/ext4/blockgroup.rst
+++ b/Documentation/filesystems/ext4/blockgroup.rst
@@ -41,8 +41,8 @@ across the disk in case the beginning of the disk gets trashed, though
 not all block groups necessarily host a redundant copy (see following
 paragraph for more details). If the group does not have a redundant
 copy, the block group begins with the data block bitmap. Note also that
-when the filesystem is freshly formatted, mkfs will allocate “reserve
-GDT block” space after the block group descriptors and before the start
+when the filesystem is freshly formatted, mkfs will allocate "reserve
+GDT block" space after the block group descriptors and before the start
 of the block bitmaps to allow for future expansion of the filesystem. By
 default, a filesystem is allowed to increase in size by a factor of
 1024x over the original filesystem size.
@@ -84,7 +84,7 @@ Without the option META\_BG, for safety concerns, all block group
 descriptors copies are kept in the first block group. Given the default
 128MiB(2^27 bytes) block group size and 64-byte group descriptors, ext4
 can have at most 2^27/64 = 2^21 block groups. This limits the entire
-filesystem size to 2^21 ∗ 2^27 = 2^48bytes or 256TiB.
+filesystem size to 2^21 * 2^27 = 2^48bytes or 256TiB.
 
 The solution to this problem is to use the metablock group feature
 (META\_BG), which is already in ext3 for all 2.6 releases. With the
@@ -131,5 +131,5 @@ rely on the kernel to initialize the inode tables in the background.
 
 By not writing zeroes to the bitmaps and inode table, mkfs time is
 reduced considerably. Note the feature flag is RO\_COMPAT\_GDT\_CSUM,
-but the dumpe2fs output prints this as “uninit\_bg”. They are the same
+but the dumpe2fs output prints this as "uninit\_bg". They are the same
 thing.
diff --git a/Documentation/filesystems/ext4/blocks.rst b/Documentation/filesystems/ext4/blocks.rst
index bd722ecd92d6..ca16435d469e 100644
--- a/Documentation/filesystems/ext4/blocks.rst
+++ b/Documentation/filesystems/ext4/blocks.rst
@@ -3,7 +3,7 @@
 Blocks
 ------
 
-ext4 allocates storage space in units of “blocks”. A block is a group of
+ext4 allocates storage space in units of "blocks". A block is a group of
 sectors between 1KiB and 64KiB, and the number of sectors must be an
 integral power of 2. Blocks are in turn grouped into larger units called
 block groups. Block size is specified at mkfs time and typically is
diff --git a/Documentation/filesystems/ext4/directory.rst b/Documentation/filesystems/ext4/directory.rst
index 55f618b37144..317e672cd457 100644
--- a/Documentation/filesystems/ext4/directory.rst
+++ b/Documentation/filesystems/ext4/directory.rst
@@ -15,8 +15,8 @@ is desired.
 Linear (Classic) Directories
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-By default, each directory lists its entries in an “almost-linear”
-array. I write “almost” because it's not a linear array in the memory
+By default, each directory lists its entries in an "almost-linear"
+array. I write "almost" because it's not a linear array in the memory
 sense because directory entries are not split across filesystem blocks.
 Therefore, it is more accurate to say that a directory is a series of
 data blocks and that each block contains a linear array of directory
@@ -26,7 +26,7 @@ takes it all the way to the end of the block. The end of the entire
 directory is of course signified by reaching the end of the file. Unused
 directory entries are signified by inode = 0. By default the filesystem
 uses ``struct ext4_dir_entry_2`` for directory entries unless the
-“filetype” feature flag is not set, in which case it uses
+"filetype" feature flag is not set, in which case it uses
 ``struct ext4_dir_entry``.
 
 The original directory entry format is ``struct ext4_dir_entry``, which
@@ -197,7 +197,7 @@ balanced tree keyed off a hash of the directory entry name. If the
 EXT4\_INDEX\_FL (0x1000) flag is set in the inode, this directory uses a
 hashed btree (htree) to organize and find directory entries. For
 backwards read-only compatibility with ext2, this tree is actually
-hidden inside the directory file, masquerading as “empty” directory data
+hidden inside the directory file, masquerading as "empty" directory data
 blocks! It was stated previously that the end of the linear directory
 entry table was signified with an entry pointing to inode 0; this is
 (ab)used to fool the old linear-scan algorithm into thinking that the
@@ -263,7 +263,7 @@ of a data block:
    * - 0x8
      - char
      - dot.name[4]
-     - “.\\0\\0\\0”
+     - ".\\0\\0\\0"
    * - 0xC
      - \_\_le32
      - dotdot.inode
@@ -284,7 +284,7 @@ of a data block:
    * - 0x14
      - char
      - dotdot\_name[4]
-     - “..\\0\\0”
+     - "..\\0\\0"
    * - 0x18
      - \_\_le32
      - struct dx\_root\_info.reserved\_zero
@@ -372,11 +372,11 @@ also the full length of a data block:
    * - 0x6
      - u8
      - name\_len
-     - Zero. There is no name for this “unused” directory entry.
+     - Zero. There is no name for this "unused" directory entry.
    * - 0x7
      - u8
      - file\_type
-     - Zero. There is no file type for this “unused” directory entry.
+     - Zero. There is no file type for this "unused" directory entry.
    * - 0x8
      - \_\_le16
      - limit
diff --git a/Documentation/filesystems/ext4/eainode.rst b/Documentation/filesystems/ext4/eainode.rst
index ecc0d01a0a72..71e64aadaa89 100644
--- a/Documentation/filesystems/ext4/eainode.rst
+++ b/Documentation/filesystems/ext4/eainode.rst
@@ -6,7 +6,7 @@ Large Extended Attribute Values
 To enable ext4 to store extended attribute values that do not fit in the
 inode or in the single extended attribute block attached to an inode,
 the EA\_INODE feature allows us to store the value in the data blocks of
-a regular file inode. This “EA inode” is linked only from the extended
+a regular file inode. This "EA inode" is linked only from the extended
 attribute name index and must not appear in a directory entry. The
 inode's i\_atime field is used to store a checksum of the xattr value;
 and i\_ctime/i\_version store a 64-bit reference count, which enables
diff --git a/Documentation/filesystems/ext4/inlinedata.rst b/Documentation/filesystems/ext4/inlinedata.rst
index d1075178ce0b..8efa8a1cf273 100644
--- a/Documentation/filesystems/ext4/inlinedata.rst
+++ b/Documentation/filesystems/ext4/inlinedata.rst
@@ -9,7 +9,7 @@ data is so tiny that it readily fits inside the inode, which
 file is smaller than 60 bytes, then the data are stored inline in
 ``inode.i_block``. If the rest of the file would fit inside the extended
 attribute space, then it might be found as an extended attribute
-“system.data” within the inode body (“ibody EA”). This of course
+"system.data" within the inode body ("ibody EA"). This of course
 constrains the amount of extended attributes one can attach to an inode.
 If the data size increases beyond i\_block + ibody EA, a regular block
 is allocated and the contents moved to that block.
@@ -20,14 +20,14 @@ inline data, one ought to be able to store 160 bytes of data in a
 that, the limit was 156 bytes due to inefficient use of inode space.
 
 The inline data feature requires the presence of an extended attribute
-for “system.data”, even if the attribute value is zero length.
+for "system.data", even if the attribute value is zero length.
 
 Inline Directories
 ~~~~~~~~~~~~~~~~~~
 
 The first four bytes of i\_block are the inode number of the parent
 directory. Following that is a 56-byte space for an array of directory
-entries; see ``struct ext4_dir_entry``. If there is a “system.data”
+entries; see ``struct ext4_dir_entry``. If there is a "system.data"
 attribute in the inode body, the EA value is an array of
 ``struct ext4_dir_entry`` as well. Note that for inline directories, the
 i\_block and EA space are treated as separate dirent blocks; directory
diff --git a/Documentation/filesystems/ext4/inodes.rst b/Documentation/filesystems/ext4/inodes.rst
index a65baffb4ebf..cd3bbc3c1e33 100644
--- a/Documentation/filesystems/ext4/inodes.rst
+++ b/Documentation/filesystems/ext4/inodes.rst
@@ -90,7 +90,7 @@ The inode table entry is laid out in ``struct ext4_inode``.
    * - 0x1C
      - \_\_le32
      - i\_blocks\_lo
-     - Lower 32-bits of “block” count. If the huge\_file feature flag is not
+     - Lower 32-bits of "block" count. If the huge\_file feature flag is not
        set on the filesystem, the file consumes ``i_blocks_lo`` 512-byte blocks
        on disk. If huge\_file is set and EXT4\_HUGE\_FILE\_FL is NOT set in
        ``inode.i_flags``, then the file consumes ``i_blocks_lo + (i_blocks_hi
@@ -109,7 +109,7 @@ The inode table entry is laid out in ``struct ext4_inode``.
    * - 0x28
      - 60 bytes
      - i\_block[EXT4\_N\_BLOCKS=15]
-     - Block map or extent tree. See the section “The Contents of inode.i\_block”.
+     - Block map or extent tree. See the section "The Contents of inode.i\_block".
    * - 0x64
      - \_\_le32
      - i\_generation
@@ -507,7 +507,7 @@ orphaned inode, or zero if there are no more orphans.
 If the inode structure size ``sb->s_inode_size`` is larger than 128
 bytes and the ``i_inode_extra`` field is large enough to encompass the
 respective ``i_[cma]time_extra`` field, the ctime, atime, and mtime
-inode fields are widened to 64 bits. Within this “extra” 32-bit field,
+inode fields are widened to 64 bits. Within this "extra" 32-bit field,
 the lower two bits are used to extend the 32-bit seconds field to be 34
 bit wide; the upper 30 bits are used to provide nanosecond timestamp
 accuracy. Therefore, timestamps should not overflow until May 2446.
diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst
index cdbfec473167..9e12d5366ad6 100644
--- a/Documentation/filesystems/ext4/journal.rst
+++ b/Documentation/filesystems/ext4/journal.rst
@@ -6,7 +6,7 @@ Journal (jbd2)
 Introduced in ext3, the ext4 filesystem employs a journal to protect the
 filesystem against corruption in the case of a system crash. A small
 continuous region of disk (default 128MiB) is reserved inside the
-filesystem as a place to land “important” data writes on-disk as quickly
+filesystem as a place to land "important" data writes on-disk as quickly
 as possible. Once the important data transaction is fully written to the
 disk and flushed from the disk write cache, a record of the data being
 committed is also written to the journal. At some later point in time,
@@ -507,7 +507,7 @@ Data Block
 In general, the data blocks being written to disk through the journal
 are written verbatim into the journal file after the descriptor block.
 However, if the first four bytes of the block match the jbd2 magic
-number then those four bytes are replaced with zeroes and the “escaped”
+number then those four bytes are replaced with zeroes and the "escaped"
 flag is set in the descriptor block tag.
 
 Revocation Block
@@ -520,8 +520,8 @@ block is freed and re-allocated as a file data block; in this case, a
 journal replay after the file block was written to disk will cause
 corruption.
 
-**NOTE**: This mechanism is NOT used to express “this journal block is
-superseded by this other journal block”, as the author (djwong)
+**NOTE**: This mechanism is NOT used to express "this journal block is
+superseded by this other journal block", as the author (djwong)
 mistakenly thought. Any block being added to a transaction will cause
 the removal of all existing revocation records for that block.
 
diff --git a/Documentation/filesystems/ext4/mmp.rst b/Documentation/filesystems/ext4/mmp.rst
index 25660981d93c..20631883a32b 100644
--- a/Documentation/filesystems/ext4/mmp.rst
+++ b/Documentation/filesystems/ext4/mmp.rst
@@ -42,7 +42,7 @@ The MMP structure (``struct mmp_struct``) is as follows:
    * - 0x0
      - \_\_le32
      - mmp\_magic
-     - Magic number for MMP, 0x004D4D50 (“MMP”).
+     - Magic number for MMP, 0x004D4D50 ("MMP").
    * - 0x4
      - \_\_le32
      - mmp\_seq
diff --git a/Documentation/filesystems/ext4/special_inodes.rst b/Documentation/filesystems/ext4/special_inodes.rst
index 9061aabba827..407537be8fe5 100644
--- a/Documentation/filesystems/ext4/special_inodes.rst
+++ b/Documentation/filesystems/ext4/special_inodes.rst
@@ -26,11 +26,11 @@ ext4 reserves some inode for special features, as follows:
    * - 6
      - Undelete directory.
    * - 7
-     - Reserved group descriptors inode. (“resize inode”)
+     - Reserved group descriptors inode. ("resize inode")
    * - 8
      - Journal inode.
    * - 9
-     - The “exclude” inode, for snapshots(?)
+     - The "exclude" inode, for snapshots(?)
    * - 10
      - Replica inode, used for some non-upstream feature?
    * - 11
diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst
index 2eb1ab20498d..8c52ccc6dd04 100644
--- a/Documentation/filesystems/ext4/super.rst
+++ b/Documentation/filesystems/ext4/super.rst
@@ -572,7 +572,7 @@ following:
    * - 0x1
      - Directory preallocation (COMPAT\_DIR\_PREALLOC).
    * - 0x2
-     - “imagic inodes”. Not clear from the code what this does
+     - "imagic inodes". Not clear from the code what this does
        (COMPAT\_IMAGIC\_INODES).
    * - 0x4
      - Has a journal (COMPAT\_HAS\_JOURNAL).
@@ -584,12 +584,12 @@ following:
    * - 0x20
      - Has directory indices (COMPAT\_DIR\_INDEX).
    * - 0x40
-     - “Lazy BG”. Not in Linux kernel, seems to have been for uninitialized
+     - "Lazy BG". Not in Linux kernel, seems to have been for uninitialized
        block groups? (COMPAT\_LAZY\_BG)
    * - 0x80
-     - “Exclude inode”. Not used. (COMPAT\_EXCLUDE\_INODE).
+     - "Exclude inode". Not used. (COMPAT\_EXCLUDE\_INODE).
    * - 0x100
-     - “Exclude bitmap”. Seems to be used to indicate the presence of
+     - "Exclude bitmap". Seems to be used to indicate the presence of
        snapshot-related exclude bitmaps? Not defined in kernel or used in
        e2fsprogs (COMPAT\_EXCLUDE\_BITMAP).
    * - 0x200
@@ -695,7 +695,7 @@ the following:
    * - 0x100
      - `Quota <Quota>`__ (RO\_COMPAT\_QUOTA).
    * - 0x200
-     - This filesystem supports “bigalloc”, which means that file extents are
+     - This filesystem supports "bigalloc", which means that file extents are
        tracked in units of clusters (of blocks) instead of blocks
        (RO\_COMPAT\_BIGALLOC).
    * - 0x400
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 29/53] docs: kernel-hacking: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (33 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet,
	Nícolas F. R. A. Prado, Bhaskar Chowdhury, Joe Pater,
	Takashi Iwai, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/kernel-hacking/hacking.rst | 2 +-
 Documentation/kernel-hacking/locking.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
index 451523424942..e8f9cff4b016 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -741,7 +741,7 @@ make a neat patch, there's administrative work to be done:
    In your description of the option, make sure you address both the
    expert user and the user who knows nothing about your feature.
    Mention incompatibilities and issues here. **Definitely** end your
-   description with “if in doubt, say N” (or, occasionally, \`Y'); this
+   description with "if in doubt, say N" (or, occasionally, \`Y'); this
    is for people who have no idea what you are talking about.
 
 -  Edit the ``Makefile``: the CONFIG variables are exported here so you
diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index ed1284c6f078..f8ab299314b4 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -872,7 +872,7 @@ the name field.
 Note also that I added a comment describing what data was protected by
 which locks. This is extremely important, as it describes the runtime
 behavior of the code, and can be hard to gain from just reading. And as
-Alan Cox says, “Lock data, not code”.
+Alan Cox says, "Lock data, not code".
 
 Common Problems
 ===============
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 30/53] docs: hid: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (34 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Mark O'Donovan,
	Jiri Kosina, Jonathan Cameron, Randy Dunlap, Srinivas Pandruvada,
	linux-iio, linux-input, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/hid/hid-sensor.rst    |  70 ++++----
 Documentation/hid/intel-ish-hid.rst | 246 ++++++++++++++--------------
 2 files changed, 158 insertions(+), 158 deletions(-)

diff --git a/Documentation/hid/hid-sensor.rst b/Documentation/hid/hid-sensor.rst
index c1c9b8d8dca6..b98d7a415cda 100644
--- a/Documentation/hid/hid-sensor.rst
+++ b/Documentation/hid/hid-sensor.rst
@@ -173,39 +173,39 @@ An example of this representation on sysfs::
 
   /sys/devices/pci0000:00/INT33C2:00/i2c-0/i2c-INT33D1:00/0018:8086:09FA.0001/HID-SENSOR-2000e1.6.auto$ tree -R
   .
-  │   ├──  enable_sensor
-  │   │   ├── feature-0-200316
-  │   │   │   ├── feature-0-200316-maximum
-  │   │   │   ├── feature-0-200316-minimum
-  │   │   │   ├── feature-0-200316-name
-  │   │   │   ├── feature-0-200316-size
-  │   │   │   ├── feature-0-200316-unit-expo
-  │   │   │   ├── feature-0-200316-units
-  │   │   │   ├── feature-0-200316-value
-  │   │   ├── feature-1-200201
-  │   │   │   ├── feature-1-200201-maximum
-  │   │   │   ├── feature-1-200201-minimum
-  │   │   │   ├── feature-1-200201-name
-  │   │   │   ├── feature-1-200201-size
-  │   │   │   ├── feature-1-200201-unit-expo
-  │   │   │   ├── feature-1-200201-units
-  │   │   │   ├── feature-1-200201-value
-  │   │   ├── input-0-200201
-  │   │   │   ├── input-0-200201-maximum
-  │   │   │   ├── input-0-200201-minimum
-  │   │   │   ├── input-0-200201-name
-  │   │   │   ├── input-0-200201-size
-  │   │   │   ├── input-0-200201-unit-expo
-  │   │   │   ├── input-0-200201-units
-  │   │   │   ├── input-0-200201-value
-  │   │   ├── input-1-200202
-  │   │   │   ├── input-1-200202-maximum
-  │   │   │   ├── input-1-200202-minimum
-  │   │   │   ├── input-1-200202-name
-  │   │   │   ├── input-1-200202-size
-  │   │   │   ├── input-1-200202-unit-expo
-  │   │   │   ├── input-1-200202-units
-  │   │   │   ├── input-1-200202-value
+  │   ├──  enable_sensor
+  │   │   ├── feature-0-200316
+  │   │   │   ├── feature-0-200316-maximum
+  │   │   │   ├── feature-0-200316-minimum
+  │   │   │   ├── feature-0-200316-name
+  │   │   │   ├── feature-0-200316-size
+  │   │   │   ├── feature-0-200316-unit-expo
+  │   │   │   ├── feature-0-200316-units
+  │   │   │   ├── feature-0-200316-value
+  │   │   ├── feature-1-200201
+  │   │   │   ├── feature-1-200201-maximum
+  │   │   │   ├── feature-1-200201-minimum
+  │   │   │   ├── feature-1-200201-name
+  │   │   │   ├── feature-1-200201-size
+  │   │   │   ├── feature-1-200201-unit-expo
+  │   │   │   ├── feature-1-200201-units
+  │   │   │   ├── feature-1-200201-value
+  │   │   ├── input-0-200201
+  │   │   │   ├── input-0-200201-maximum
+  │   │   │   ├── input-0-200201-minimum
+  │   │   │   ├── input-0-200201-name
+  │   │   │   ├── input-0-200201-size
+  │   │   │   ├── input-0-200201-unit-expo
+  │   │   │   ├── input-0-200201-units
+  │   │   │   ├── input-0-200201-value
+  │   │   ├── input-1-200202
+  │   │   │   ├── input-1-200202-maximum
+  │   │   │   ├── input-1-200202-minimum
+  │   │   │   ├── input-1-200202-name
+  │   │   │   ├── input-1-200202-size
+  │   │   │   ├── input-1-200202-unit-expo
+  │   │   │   ├── input-1-200202-units
+  │   │   │   ├── input-1-200202-value
 
 Here there is a custom sensor with four fields: two feature and two inputs.
 Each field is represented by a set of attributes. All fields except the "value"
@@ -234,8 +234,8 @@ Once enabled and powered on, sensor can report value using HID reports.
 These reports are pushed using misc device interface in a FIFO order::
 
 	/dev$ tree | grep HID-SENSOR-2000e1.6.auto
-	│   │   │   ├── 10:53 -> ../HID-SENSOR-2000e1.6.auto
-	│   ├──  HID-SENSOR-2000e1.6.auto
+	│   │   │   ├── 10:53 -> ../HID-SENSOR-2000e1.6.auto
+	│   ├──  HID-SENSOR-2000e1.6.auto
 
 Each report can be of variable length preceded by a header. This header
 consists of a 32-bit usage id, 64-bit time stamp and 32-bit length field of raw
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 7a851252267a..a525cdefc937 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -355,133 +355,133 @@ To debug ISH, event tracing mechanism is used. To enable debug logs::
   root@otcpl-ThinkPad-Yoga-260:~# tree -l /sys/bus/iio/devices/
   /sys/bus/iio/devices/
   ├── iio:device0 -> ../../../devices/0044:8086:22D8.0001/HID-SENSOR-200073.9.auto/iio:device0
-  │   ├── buffer
-  │   │   ├── enable
-  │   │   ├── length
-  │   │   └── watermark
+  │   ├── buffer
+  │   │   ├── enable
+  │   │   ├── length
+  │   │   └── watermark
   ...
-  │   ├── in_accel_hysteresis
-  │   ├── in_accel_offset
-  │   ├── in_accel_sampling_frequency
-  │   ├── in_accel_scale
-  │   ├── in_accel_x_raw
-  │   ├── in_accel_y_raw
-  │   ├── in_accel_z_raw
-  │   ├── name
-  │   ├── scan_elements
-  │   │   ├── in_accel_x_en
-  │   │   ├── in_accel_x_index
-  │   │   ├── in_accel_x_type
-  │   │   ├── in_accel_y_en
-  │   │   ├── in_accel_y_index
-  │   │   ├── in_accel_y_type
-  │   │   ├── in_accel_z_en
-  │   │   ├── in_accel_z_index
-  │   │   └── in_accel_z_type
+  │   ├── in_accel_hysteresis
+  │   ├── in_accel_offset
+  │   ├── in_accel_sampling_frequency
+  │   ├── in_accel_scale
+  │   ├── in_accel_x_raw
+  │   ├── in_accel_y_raw
+  │   ├── in_accel_z_raw
+  │   ├── name
+  │   ├── scan_elements
+  │   │   ├── in_accel_x_en
+  │   │   ├── in_accel_x_index
+  │   │   ├── in_accel_x_type
+  │   │   ├── in_accel_y_en
+  │   │   ├── in_accel_y_index
+  │   │   ├── in_accel_y_type
+  │   │   ├── in_accel_z_en
+  │   │   ├── in_accel_z_index
+  │   │   └── in_accel_z_type
   ...
-  │   │   ├── devices
-  │   │   │   │   ├── buffer
-  │   │   │   │   │   ├── enable
-  │   │   │   │   │   ├── length
-  │   │   │   │   │   └── watermark
-  │   │   │   │   ├── dev
-  │   │   │   │   ├── in_intensity_both_raw
-  │   │   │   │   ├── in_intensity_hysteresis
-  │   │   │   │   ├── in_intensity_offset
-  │   │   │   │   ├── in_intensity_sampling_frequency
-  │   │   │   │   ├── in_intensity_scale
-  │   │   │   │   ├── name
-  │   │   │   │   ├── scan_elements
-  │   │   │   │   │   ├── in_intensity_both_en
-  │   │   │   │   │   ├── in_intensity_both_index
-  │   │   │   │   │   └── in_intensity_both_type
-  │   │   │   │   ├── trigger
-  │   │   │   │   │   └── current_trigger
+  │   │   ├── devices
+  │   │   │   │   ├── buffer
+  │   │   │   │   │   ├── enable
+  │   │   │   │   │   ├── length
+  │   │   │   │   │   └── watermark
+  │   │   │   │   ├── dev
+  │   │   │   │   ├── in_intensity_both_raw
+  │   │   │   │   ├── in_intensity_hysteresis
+  │   │   │   │   ├── in_intensity_offset
+  │   │   │   │   ├── in_intensity_sampling_frequency
+  │   │   │   │   ├── in_intensity_scale
+  │   │   │   │   ├── name
+  │   │   │   │   ├── scan_elements
+  │   │   │   │   │   ├── in_intensity_both_en
+  │   │   │   │   │   ├── in_intensity_both_index
+  │   │   │   │   │   └── in_intensity_both_type
+  │   │   │   │   ├── trigger
+  │   │   │   │   │   └── current_trigger
   ...
-  │   │   │   │   ├── buffer
-  │   │   │   │   │   ├── enable
-  │   │   │   │   │   ├── length
-  │   │   │   │   │   └── watermark
-  │   │   │   │   ├── dev
-  │   │   │   │   ├── in_magn_hysteresis
-  │   │   │   │   ├── in_magn_offset
-  │   │   │   │   ├── in_magn_sampling_frequency
-  │   │   │   │   ├── in_magn_scale
-  │   │   │   │   ├── in_magn_x_raw
-  │   │   │   │   ├── in_magn_y_raw
-  │   │   │   │   ├── in_magn_z_raw
-  │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_raw
-  │   │   │   │   ├── in_rot_hysteresis
-  │   │   │   │   ├── in_rot_offset
-  │   │   │   │   ├── in_rot_sampling_frequency
-  │   │   │   │   ├── in_rot_scale
-  │   │   │   │   ├── name
+  │   │   │   │   ├── buffer
+  │   │   │   │   │   ├── enable
+  │   │   │   │   │   ├── length
+  │   │   │   │   │   └── watermark
+  │   │   │   │   ├── dev
+  │   │   │   │   ├── in_magn_hysteresis
+  │   │   │   │   ├── in_magn_offset
+  │   │   │   │   ├── in_magn_sampling_frequency
+  │   │   │   │   ├── in_magn_scale
+  │   │   │   │   ├── in_magn_x_raw
+  │   │   │   │   ├── in_magn_y_raw
+  │   │   │   │   ├── in_magn_z_raw
+  │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_raw
+  │   │   │   │   ├── in_rot_hysteresis
+  │   │   │   │   ├── in_rot_offset
+  │   │   │   │   ├── in_rot_sampling_frequency
+  │   │   │   │   ├── in_rot_scale
+  │   │   │   │   ├── name
   ...
-  │   │   │   │   ├── scan_elements
-  │   │   │   │   │   ├── in_magn_x_en
-  │   │   │   │   │   ├── in_magn_x_index
-  │   │   │   │   │   ├── in_magn_x_type
-  │   │   │   │   │   ├── in_magn_y_en
-  │   │   │   │   │   ├── in_magn_y_index
-  │   │   │   │   │   ├── in_magn_y_type
-  │   │   │   │   │   ├── in_magn_z_en
-  │   │   │   │   │   ├── in_magn_z_index
-  │   │   │   │   │   ├── in_magn_z_type
-  │   │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_en
-  │   │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_index
-  │   │   │   │   │   └── in_rot_from_north_magnetic_tilt_comp_type
-  │   │   │   │   ├── trigger
-  │   │   │   │   │   └── current_trigger
+  │   │   │   │   ├── scan_elements
+  │   │   │   │   │   ├── in_magn_x_en
+  │   │   │   │   │   ├── in_magn_x_index
+  │   │   │   │   │   ├── in_magn_x_type
+  │   │   │   │   │   ├── in_magn_y_en
+  │   │   │   │   │   ├── in_magn_y_index
+  │   │   │   │   │   ├── in_magn_y_type
+  │   │   │   │   │   ├── in_magn_z_en
+  │   │   │   │   │   ├── in_magn_z_index
+  │   │   │   │   │   ├── in_magn_z_type
+  │   │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_en
+  │   │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_index
+  │   │   │   │   │   └── in_rot_from_north_magnetic_tilt_comp_type
+  │   │   │   │   ├── trigger
+  │   │   │   │   │   └── current_trigger
   ...
-  │   │   │   │   ├── buffer
-  │   │   │   │   │   ├── enable
-  │   │   │   │   │   ├── length
-  │   │   │   │   │   └── watermark
-  │   │   │   │   ├── dev
-  │   │   │   │   ├── in_anglvel_hysteresis
-  │   │   │   │   ├── in_anglvel_offset
-  │   │   │   │   ├── in_anglvel_sampling_frequency
-  │   │   │   │   ├── in_anglvel_scale
-  │   │   │   │   ├── in_anglvel_x_raw
-  │   │   │   │   ├── in_anglvel_y_raw
-  │   │   │   │   ├── in_anglvel_z_raw
-  │   │   │   │   ├── name
-  │   │   │   │   ├── scan_elements
-  │   │   │   │   │   ├── in_anglvel_x_en
-  │   │   │   │   │   ├── in_anglvel_x_index
-  │   │   │   │   │   ├── in_anglvel_x_type
-  │   │   │   │   │   ├── in_anglvel_y_en
-  │   │   │   │   │   ├── in_anglvel_y_index
-  │   │   │   │   │   ├── in_anglvel_y_type
-  │   │   │   │   │   ├── in_anglvel_z_en
-  │   │   │   │   │   ├── in_anglvel_z_index
-  │   │   │   │   │   └── in_anglvel_z_type
-  │   │   │   │   ├── trigger
-  │   │   │   │   │   └── current_trigger
+  │   │   │   │   ├── buffer
+  │   │   │   │   │   ├── enable
+  │   │   │   │   │   ├── length
+  │   │   │   │   │   └── watermark
+  │   │   │   │   ├── dev
+  │   │   │   │   ├── in_anglvel_hysteresis
+  │   │   │   │   ├── in_anglvel_offset
+  │   │   │   │   ├── in_anglvel_sampling_frequency
+  │   │   │   │   ├── in_anglvel_scale
+  │   │   │   │   ├── in_anglvel_x_raw
+  │   │   │   │   ├── in_anglvel_y_raw
+  │   │   │   │   ├── in_anglvel_z_raw
+  │   │   │   │   ├── name
+  │   │   │   │   ├── scan_elements
+  │   │   │   │   │   ├── in_anglvel_x_en
+  │   │   │   │   │   ├── in_anglvel_x_index
+  │   │   │   │   │   ├── in_anglvel_x_type
+  │   │   │   │   │   ├── in_anglvel_y_en
+  │   │   │   │   │   ├── in_anglvel_y_index
+  │   │   │   │   │   ├── in_anglvel_y_type
+  │   │   │   │   │   ├── in_anglvel_z_en
+  │   │   │   │   │   ├── in_anglvel_z_index
+  │   │   │   │   │   └── in_anglvel_z_type
+  │   │   │   │   ├── trigger
+  │   │   │   │   │   └── current_trigger
   ...
-  │   │   │   │   ├── buffer
-  │   │   │   │   │   ├── enable
-  │   │   │   │   │   ├── length
-  │   │   │   │   │   └── watermark
-  │   │   │   │   ├── dev
-  │   │   │   │   ├── in_anglvel_hysteresis
-  │   │   │   │   ├── in_anglvel_offset
-  │   │   │   │   ├── in_anglvel_sampling_frequency
-  │   │   │   │   ├── in_anglvel_scale
-  │   │   │   │   ├── in_anglvel_x_raw
-  │   │   │   │   ├── in_anglvel_y_raw
-  │   │   │   │   ├── in_anglvel_z_raw
-  │   │   │   │   ├── name
-  │   │   │   │   ├── scan_elements
-  │   │   │   │   │   ├── in_anglvel_x_en
-  │   │   │   │   │   ├── in_anglvel_x_index
-  │   │   │   │   │   ├── in_anglvel_x_type
-  │   │   │   │   │   ├── in_anglvel_y_en
-  │   │   │   │   │   ├── in_anglvel_y_index
-  │   │   │   │   │   ├── in_anglvel_y_type
-  │   │   │   │   │   ├── in_anglvel_z_en
-  │   │   │   │   │   ├── in_anglvel_z_index
-  │   │   │   │   │   └── in_anglvel_z_type
-  │   │   │   │   ├── trigger
-  │   │   │   │   │   └── current_trigger
+  │   │   │   │   ├── buffer
+  │   │   │   │   │   ├── enable
+  │   │   │   │   │   ├── length
+  │   │   │   │   │   └── watermark
+  │   │   │   │   ├── dev
+  │   │   │   │   ├── in_anglvel_hysteresis
+  │   │   │   │   ├── in_anglvel_offset
+  │   │   │   │   ├── in_anglvel_sampling_frequency
+  │   │   │   │   ├── in_anglvel_scale
+  │   │   │   │   ├── in_anglvel_x_raw
+  │   │   │   │   ├── in_anglvel_y_raw
+  │   │   │   │   ├── in_anglvel_z_raw
+  │   │   │   │   ├── name
+  │   │   │   │   ├── scan_elements
+  │   │   │   │   │   ├── in_anglvel_x_en
+  │   │   │   │   │   ├── in_anglvel_x_index
+  │   │   │   │   │   ├── in_anglvel_x_type
+  │   │   │   │   │   ├── in_anglvel_y_en
+  │   │   │   │   │   ├── in_anglvel_y_index
+  │   │   │   │   │   ├── in_anglvel_y_type
+  │   │   │   │   │   ├── in_anglvel_z_en
+  │   │   │   │   │   ├── in_anglvel_z_index
+  │   │   │   │   │   └── in_anglvel_z_type
+  │   │   │   │   ├── trigger
+  │   │   │   │   │   └── current_trigger
   ...
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 31/53] docs: security: tpm: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (35 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/security/tpm/tpm_event_log.rst | 2 +-
 Documentation/security/tpm/xen-tpmfront.rst  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/security/tpm/tpm_event_log.rst b/Documentation/security/tpm/tpm_event_log.rst
index f00f7a1d5e92..9f2716c170bb 100644
--- a/Documentation/security/tpm/tpm_event_log.rst
+++ b/Documentation/security/tpm/tpm_event_log.rst
@@ -20,7 +20,7 @@ process.
 The main application for this is remote attestation and the reason why
 it is useful is nicely put in the very first section of [1]:
 
-"Attestation is used to provide information about the platform’s state
+"Attestation is used to provide information about the platform's state
 to a challenger. However, PCR contents are difficult to interpret;
 therefore, attestation is typically more useful when the PCR contents
 are accompanied by a measurement log. While not trusted on their own,
diff --git a/Documentation/security/tpm/xen-tpmfront.rst b/Documentation/security/tpm/xen-tpmfront.rst
index 00d5b1db227d..31c67522f2ad 100644
--- a/Documentation/security/tpm/xen-tpmfront.rst
+++ b/Documentation/security/tpm/xen-tpmfront.rst
@@ -1,4 +1,4 @@
-=============================
+=============================
 Virtual TPM interface for Xen
 =============================
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 32/53] docs: security: keys: trusted-encrypted.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (36 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, James Bottomley,
	Jarkko Sakkinen, Mimi Zohar, keyrings, linux-integrity,
	linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/security/keys/trusted-encrypted.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 80d5a5af62a1..3697cbb4fc2c 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -108,8 +108,8 @@ Encrypted Keys
 
 Encrypted keys do not depend on a trust source, and are faster, as they use AES
 for encryption/decryption. New keys are created from kernel-generated random
-numbers, and are encrypted/decrypted using a specified ‘master’ key. The
-‘master’ key can either be a trusted-key or user-key type. The main disadvantage
+numbers, and are encrypted/decrypted using a specified 'master' key. The
+'master' key can either be a trusted-key or user-key type. The main disadvantage
 of encrypted keys is that if they are not rooted in a trusted key, they are only
 as secure as the user key encrypting them. The master user key should therefore
 be loaded in as secure a way as possible, preferably early in boot.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 33/53] docs: riscv: vm-layout.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Albert Ou,
	Alexandre Ghiti, Palmer Dabbelt, Paul Walmsley, linux-kernel,
	linux-riscv

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/riscv/vm-layout.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 329d32098af4..545f8ab51f1a 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63–48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 33/53] docs: riscv: vm-layout.rst: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Albert Ou,
	Alexandre Ghiti, Palmer Dabbelt, Paul Walmsley, linux-kernel,
	linux-riscv

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/riscv/vm-layout.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 329d32098af4..545f8ab51f1a 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63–48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
-- 
2.30.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 34/53] docs: networking: scaling.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (38 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, David S. Miller, Jonathan Corbet,
	Jakub Kicinski, linux-kernel, netdev

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/networking/scaling.rst | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/networking/scaling.rst b/Documentation/networking/scaling.rst
index 3d435caa3ef2..e1a0c88193fa 100644
--- a/Documentation/networking/scaling.rst
+++ b/Documentation/networking/scaling.rst
@@ -30,7 +30,7 @@ queues to distribute processing among CPUs. The NIC distributes packets by
 applying a filter to each packet that assigns it to one of a small number
 of logical flows. Packets for each flow are steered to a separate receive
 queue, which in turn can be processed by separate CPUs. This mechanism is
-generally known as “Receive-side Scaling” (RSS). The goal of RSS and
+generally known as "Receive-side Scaling" (RSS). The goal of RSS and
 the other scaling techniques is to increase performance uniformly.
 Multi-queue distribution can also be used for traffic prioritization, but
 that is not the focus of these techniques.
@@ -46,7 +46,7 @@ indirection table and reading the corresponding value.
 
 Some advanced NICs allow steering packets to queues based on
 programmable filters. For example, webserver bound TCP port 80 packets
-can be directed to their own receive queue. Such “n-tuple” filters can
+can be directed to their own receive queue. Such "n-tuple" filters can
 be configured from ethtool (--config-ntuple).
 
 
@@ -114,7 +114,7 @@ RSS. Being in software, it is necessarily called later in the datapath.
 Whereas RSS selects the queue and hence CPU that will run the hardware
 interrupt handler, RPS selects the CPU to perform protocol processing
 above the interrupt handler. This is accomplished by placing the packet
-on the desired CPU’s backlog queue and waking up the CPU for processing.
+on the desired CPU's backlog queue and waking up the CPU for processing.
 RPS has some advantages over RSS:
 
 1) it can be used with any NIC
@@ -128,20 +128,20 @@ netif_receive_skb(). These call the get_rps_cpu() function, which
 selects the queue that should process a packet.
 
 The first step in determining the target CPU for RPS is to calculate a
-flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
+flow hash over the packet's addresses or ports (2-tuple or 4-tuple hash
 depending on the protocol). This serves as a consistent hash of the
 associated flow of the packet. The hash is either provided by hardware
 or will be computed in the stack. Capable hardware can pass the hash in
 the receive descriptor for the packet; this would usually be the same
 hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
 skb->hash and can be used elsewhere in the stack as a hash of the
-packet’s flow.
+packet's flow.
 
 Each receive hardware queue has an associated list of CPUs to which
 RPS may enqueue packets for processing. For each received packet,
 an index into the list is computed from the flow hash modulo the size
 of the list. The indexed CPU is the target for processing the packet,
-and the packet is queued to the tail of that CPU’s backlog queue. At
+and the packet is queued to the tail of that CPU's backlog queue. At
 the end of the bottom half routine, IPIs are sent to any CPUs for which
 packets have been queued to their backlog queue. The IPI wakes backlog
 processing on the remote CPU, and any queued packets are then processed
@@ -298,7 +298,7 @@ CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
 and the rps_dev_flow table of the queue that the packet was received on
 are compared. If the desired CPU for the flow (found in the
 rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
-table), the packet is enqueued onto that CPU’s backlog. If they differ,
+table), the packet is enqueued onto that CPU's backlog. If they differ,
 the current CPU is updated to match the desired CPU if one of the
 following is true:
 
@@ -356,7 +356,7 @@ the application thread consuming the packets of each flow is running.
 Accelerated RFS should perform better than RFS since packets are sent
 directly to a CPU local to the thread consuming the data. The target CPU
 will either be the same CPU where the application runs, or at least a CPU
-which is local to the application thread’s CPU in the cache hierarchy.
+which is local to the application thread's CPU in the cache hierarchy.
 
 To enable accelerated RFS, the networking stack calls the
 ndo_rx_flow_steer driver function to communicate the desired hardware
@@ -369,7 +369,7 @@ The hardware queue for a flow is derived from the CPU recorded in
 rps_dev_flow_table. The stack consults a CPU to hardware queue map which
 is maintained by the NIC driver. This is an auto-generated reverse map of
 the IRQ affinity table shown by /proc/interrupts. Drivers can use
-functions in the cpu_rmap (“CPU affinity reverse map”) kernel library
+functions in the cpu_rmap ("CPU affinity reverse map") kernel library
 to populate the map. For each CPU, the corresponding queue in the map is
 set to be one whose processing CPU is closest in cache locality.
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 35/53] docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (39 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, David S. Miller, Jonathan Corbet,
	Jakub Kicinski, Jiri Pirko, linux-kernel, netdev

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/networking/devlink/devlink-dpipe.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/networking/devlink/devlink-dpipe.rst b/Documentation/networking/devlink/devlink-dpipe.rst
index af37f250df43..2df7cbf1ba70 100644
--- a/Documentation/networking/devlink/devlink-dpipe.rst
+++ b/Documentation/networking/devlink/devlink-dpipe.rst
@@ -52,7 +52,7 @@ purposes as a standard complementary tool. The system's view from
 ``devlink-dpipe`` should change according to the changes done by the
 standard configuration tools.
 
-For example, it’s quite common to  implement Access Control Lists (ACL)
+For example, it's quite common to  implement Access Control Lists (ACL)
 using Ternary Content Addressable Memory (TCAM). The TCAM memory can be
 divided into TCAM regions. Complex TC filters can have multiple rules with
 different priorities and different lookup keys. On the other hand hardware
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 36/53] docs: networking: device_drivers: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, David S. Miller, Jonathan Corbet,
	Jakub Kicinski, Jeff Kirsher, Jesse Brandeburg, Shannon Nelson,
	Tony Nguyen, intel-wired-lan, linux-kernel, netdev

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2013 ('–'): EN DASH
	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../device_drivers/ethernet/intel/i40e.rst           | 12 ++++++------
 .../device_drivers/ethernet/intel/iavf.rst           |  6 +++---
 .../device_drivers/ethernet/netronome/nfp.rst        | 12 ++++++------
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 8a9b18573688..64024c77c9ca 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool –K [adapter] ntuple [off|on]
+  ethtool -K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -466,7 +466,7 @@ network. PTP support varies among Intel devices that support this driver. Use
 "ethtool -T <netdev name>" to get a definitive list of PTP capabilities
 supported by the device.
 
-IEEE 802.1ad (QinQ) Support
+IEEE 802.1ad (QinQ) Support
 ---------------------------
 The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
 IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
@@ -523,8 +523,8 @@ of a port's bandwidth (should it be available). The sum of all the values for
 Maximum Bandwidth is not restricted, because no more than 100% of a port's
 bandwidth can ever be used.
 
-NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
-per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
+NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
+per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
 "add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than
 64 virtual functions (VFs).
 
@@ -680,7 +680,7 @@ queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
 number of queues for all tcs is 64 or number of cores, whichever is lower.)
 
-hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
+hw 1 mode channel: 'channel' with 'hw' set to 1 is a new new hardware
 offload mode in mqprio that makes full use of the mqprio options, the
 TCs, the queue configurations, and the QoS parameters.
 
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar –n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 52e037b11c97..25e98494b385 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -113,7 +113,7 @@ which the AVF is associated. The following are base mode features:
 - AVF device ID
 - HW mailbox is used for VF to PF communications (including on Windows)
 
-IEEE 802.1ad (QinQ) Support
+IEEE 802.1ad (QinQ) Support
 ---------------------------
 The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
 IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
@@ -171,7 +171,7 @@ queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
 number of queues for all tcs is 64 or number of cores, whichever is lower.)
 
-hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
+hw 1 mode channel: 'channel' with 'hw' set to 1 is a new new hardware
 offload mode in mqprio that makes full use of the mqprio options, the
 TCs, the queue configurations, and the QoS parameters.
 
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar –n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
index ada611fb427c..949c036e8667 100644
--- a/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
+++ b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
@@ -62,14 +62,14 @@ actual firmware files in application-named subdirectories in
     $ tree /lib/firmware/netronome/
     /lib/firmware/netronome/
     ├── bpf
-    │   ├── nic_AMDA0081-0001_1x40.nffw
-    │   └── nic_AMDA0081-0001_4x10.nffw
+    │   ├── nic_AMDA0081-0001_1x40.nffw
+    │   └── nic_AMDA0081-0001_4x10.nffw
     ├── flower
-    │   ├── nic_AMDA0081-0001_1x40.nffw
-    │   └── nic_AMDA0081-0001_4x10.nffw
+    │   ├── nic_AMDA0081-0001_1x40.nffw
+    │   └── nic_AMDA0081-0001_4x10.nffw
     ├── nic
-    │   ├── nic_AMDA0081-0001_1x40.nffw
-    │   └── nic_AMDA0081-0001_4x10.nffw
+    │   ├── nic_AMDA0081-0001_1x40.nffw
+    │   └── nic_AMDA0081-0001_4x10.nffw
     ├── nic_AMDA0081-0001_1x40.nffw -> bpf/nic_AMDA0081-0001_1x40.nffw
     └── nic_AMDA0081-0001_4x10.nffw -> bpf/nic_AMDA0081-0001_4x10.nffw
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 36/53] docs: networking: device_drivers: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: intel-wired-lan

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 ('?'): NO-BREAK SPACE
	- U+2013 ('?'): EN DASH
	- U+2018 ('?'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('?'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../device_drivers/ethernet/intel/i40e.rst           | 12 ++++++------
 .../device_drivers/ethernet/intel/iavf.rst           |  6 +++---
 .../device_drivers/ethernet/netronome/nfp.rst        | 12 ++++++------
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 8a9b18573688..64024c77c9ca 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool ?K [adapter] ntuple [off|on]
+  ethtool -K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -466,7 +466,7 @@ network. PTP support varies among Intel devices that support this driver. Use
 "ethtool -T <netdev name>" to get a definitive list of PTP capabilities
 supported by the device.
 
-IEEE 802.1ad (QinQ)?Support
+IEEE 802.1ad (QinQ) Support
 ---------------------------
 The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
 IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
@@ -523,8 +523,8 @@ of a port's bandwidth (should it be available). The sum of all the values for
 Maximum Bandwidth is not restricted, because no more than 100% of a port's
 bandwidth can ever be used.
 
-NOTE:?X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
-per Port (MFP)?and SR-IOV are enabled. An error from i40e is logged that says
+NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
+per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
 "add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than
 64 virtual functions (VFs).
 
@@ -680,7 +680,7 @@ queues: for each tc, <num queues>@<offset> (e.g. queues 16 at 0 16 at 16 assigns
 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
 number of queues for all tcs is 64 or number of cores, whichever is lower.)
 
-hw 1 mode channel: ?channel? with ?hw? set to 1 is a new new hardware
+hw 1 mode channel: 'channel' with 'hw' set to 1 is a new new hardware
 offload mode in mqprio that makes full use of the mqprio options, the
 TCs, the queue configurations, and the QoS parameters.
 
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar ?n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 52e037b11c97..25e98494b385 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -113,7 +113,7 @@ which the AVF is associated. The following are base mode features:
 - AVF device ID
 - HW mailbox is used for VF to PF communications (including on Windows)
 
-IEEE 802.1ad (QinQ)?Support
+IEEE 802.1ad (QinQ) Support
 ---------------------------
 The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
 IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
@@ -171,7 +171,7 @@ queues: for each tc, <num queues>@<offset> (e.g. queues 16 at 0 16 at 16 assigns
 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
 number of queues for all tcs is 64 or number of cores, whichever is lower.)
 
-hw 1 mode channel: ?channel? with ?hw? set to 1 is a new new hardware
+hw 1 mode channel: 'channel' with 'hw' set to 1 is a new new hardware
 offload mode in mqprio that makes full use of the mqprio options, the
 TCs, the queue configurations, and the QoS parameters.
 
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar ?n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
index ada611fb427c..949c036e8667 100644
--- a/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
+++ b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
@@ -62,14 +62,14 @@ actual firmware files in application-named subdirectories in
     $ tree /lib/firmware/netronome/
     /lib/firmware/netronome/
     ??? bpf
-    ??? ??? nic_AMDA0081-0001_1x40.nffw
-    ??? ??? nic_AMDA0081-0001_4x10.nffw
+    ?   ??? nic_AMDA0081-0001_1x40.nffw
+    ?   ??? nic_AMDA0081-0001_4x10.nffw
     ??? flower
-    ??? ??? nic_AMDA0081-0001_1x40.nffw
-    ??? ??? nic_AMDA0081-0001_4x10.nffw
+    ?   ??? nic_AMDA0081-0001_1x40.nffw
+    ?   ??? nic_AMDA0081-0001_4x10.nffw
     ??? nic
-    ??? ??? nic_AMDA0081-0001_1x40.nffw
-    ??? ??? nic_AMDA0081-0001_4x10.nffw
+    ?   ??? nic_AMDA0081-0001_1x40.nffw
+    ?   ??? nic_AMDA0081-0001_4x10.nffw
     ??? nic_AMDA0081-0001_1x40.nffw -> bpf/nic_AMDA0081-0001_1x40.nffw
     ??? nic_AMDA0081-0001_4x10.nffw -> bpf/nic_AMDA0081-0001_4x10.nffw
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 37/53] docs: x86: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (41 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, H. Peter Anvin, Jonathan Corbet,
	Borislav Petkov, Dave Hansen, Fenghua Yu, Ingo Molnar,
	Jarkko Sakkinen, Reinette Chatre, Thomas Gleixner, linux-kernel,
	linux-sgx, x86

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/x86/resctrl.rst | 2 +-
 Documentation/x86/sgx.rst     | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
index 71a531061e4e..511cd5b76ed1 100644
--- a/Documentation/x86/resctrl.rst
+++ b/Documentation/x86/resctrl.rst
@@ -519,7 +519,7 @@ Cache pseudo-locking increases the probability that data will remain
 in the cache via carefully configuring the CAT feature and controlling
 application behavior. There is no guarantee that data is placed in
 cache. Instructions like INVD, WBINVD, CLFLUSH, etc. can still evict
-“locked” data from cache. Power management C-states may shrink or
+"locked" data from cache. Power management C-states may shrink or
 power off cache. Deeper C-states will automatically be restricted on
 pseudo-locked region creation.
 
diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
index dd0ac96ff9ef..7ccf63d0d083 100644
--- a/Documentation/x86/sgx.rst
+++ b/Documentation/x86/sgx.rst
@@ -88,7 +88,7 @@ Enclave build functions
 -----------------------
 
 In addition to the traditional compiler and linker build process, SGX has a
-separate enclave “build” process.  Enclaves must be built before they can be
+separate enclave "build" process.  Enclaves must be built before they can be
 executed (entered). The first step in building an enclave is opening the
 **/dev/sgx_enclave** device.  Since enclave memory is protected from direct
 access, special privileged instructions are Then used to copy data into enclave
@@ -147,7 +147,7 @@ Page reclaimer
 
 Similar to the core kswapd, ksgxd, is responsible for managing the
 overcommitment of enclave memory.  If the system runs out of enclave memory,
-*ksgxwapd* “swaps” enclave memory to normal memory.
+*ksgxwapd* "swaps" enclave memory to normal memory.
 
 Launch Control
 ==============
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 38/53] docs: scheduler: sched-deadline.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (42 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Joe Perches, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH
	- U+2212 ('−'): MINUS SIGN

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/scheduler/sched-deadline.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 9d9be52f221a..0ff353ecf24e 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -359,7 +359,7 @@ Deadline Task Scheduling
  More precisely, it can be proven that using a global EDF scheduler the
  maximum tardiness of each task is smaller or equal than
 
-	((M − 1) · WCET_max − WCET_min)/(M − (M − 2) · U_max) + WCET_max
+	((M - 1) · WCET_max - WCET_min)/(M - (M - 2) · U_max) + WCET_max
 
  where WCET_max = max{WCET_i} is the maximum WCET, WCET_min=min{WCET_i}
  is the minimum WCET, and U_max = max{WCET_i/P_i} is the maximum
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2–3, pp. 187–205, 2003.
+       vol. 25, no. 2-3, pp. 187-205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 39/53] docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (43 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 10:48   ` Marco Elver
  2021-05-10 23:35   ` David Gow
  -1 siblings, 2 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Daniel Latypov,
	David Gow, Marco Elver, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/dev-tools/testing-overview.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index b5b46709969c..8adffc26a2ec 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel — particularly specific
-parts of the kernel — then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel - particularly specific
+parts of the kernel - then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 40/53] docs: power: powercap: powercap.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (44 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Rafael J. Wysocki,
	Len Brown, Pavel Machek, Srinivas Pandruvada, Sumeet Pawnikar,
	Zhang Rui, linux-kernel, linux-pm

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/power/powercap/powercap.rst | 210 +++++++++++-----------
 1 file changed, 105 insertions(+), 105 deletions(-)

diff --git a/Documentation/power/powercap/powercap.rst b/Documentation/power/powercap/powercap.rst
index e75d12596dac..c99122e0a1c8 100644
--- a/Documentation/power/powercap/powercap.rst
+++ b/Documentation/power/powercap/powercap.rst
@@ -34,113 +34,113 @@ Example sysfs interface tree::
   /sys/devices/virtual/powercap
   └──intel-rapl
       ├──intel-rapl:0
-      │   ├──constraint_0_name
-      │   ├──constraint_0_power_limit_uw
-      │   ├──constraint_0_time_window_us
-      │   ├──constraint_1_name
-      │   ├──constraint_1_power_limit_uw
-      │   ├──constraint_1_time_window_us
-      │   ├──device -> ../../intel-rapl
-      │   ├──energy_uj
-      │   ├──intel-rapl:0:0
-      │   │   ├──constraint_0_name
-      │   │   ├──constraint_0_power_limit_uw
-      │   │   ├──constraint_0_time_window_us
-      │   │   ├──constraint_1_name
-      │   │   ├──constraint_1_power_limit_uw
-      │   │   ├──constraint_1_time_window_us
-      │   │   ├──device -> ../../intel-rapl:0
-      │   │   ├──energy_uj
-      │   │   ├──max_energy_range_uj
-      │   │   ├──name
-      │   │   ├──enabled
-      │   │   ├──power
-      │   │   │   ├──async
-      │   │   │   []
-      │   │   ├──subsystem -> ../../../../../../class/power_cap
-      │   │   └──uevent
-      │   ├──intel-rapl:0:1
-      │   │   ├──constraint_0_name
-      │   │   ├──constraint_0_power_limit_uw
-      │   │   ├──constraint_0_time_window_us
-      │   │   ├──constraint_1_name
-      │   │   ├──constraint_1_power_limit_uw
-      │   │   ├──constraint_1_time_window_us
-      │   │   ├──device -> ../../intel-rapl:0
-      │   │   ├──energy_uj
-      │   │   ├──max_energy_range_uj
-      │   │   ├──name
-      │   │   ├──enabled
-      │   │   ├──power
-      │   │   │   ├──async
-      │   │   │   []
-      │   │   ├──subsystem -> ../../../../../../class/power_cap
-      │   │   └──uevent
-      │   ├──max_energy_range_uj
-      │   ├──max_power_range_uw
-      │   ├──name
-      │   ├──enabled
-      │   ├──power
-      │   │   ├──async
-      │   │   []
-      │   ├──subsystem -> ../../../../../class/power_cap
-      │   ├──enabled
-      │   ├──uevent
+      │   ├──constraint_0_name
+      │   ├──constraint_0_power_limit_uw
+      │   ├──constraint_0_time_window_us
+      │   ├──constraint_1_name
+      │   ├──constraint_1_power_limit_uw
+      │   ├──constraint_1_time_window_us
+      │   ├──device -> ../../intel-rapl
+      │   ├──energy_uj
+      │   ├──intel-rapl:0:0
+      │   │   ├──constraint_0_name
+      │   │   ├──constraint_0_power_limit_uw
+      │   │   ├──constraint_0_time_window_us
+      │   │   ├──constraint_1_name
+      │   │   ├──constraint_1_power_limit_uw
+      │   │   ├──constraint_1_time_window_us
+      │   │   ├──device -> ../../intel-rapl:0
+      │   │   ├──energy_uj
+      │   │   ├──max_energy_range_uj
+      │   │   ├──name
+      │   │   ├──enabled
+      │   │   ├──power
+      │   │   │   ├──async
+      │   │   │   []
+      │   │   ├──subsystem -> ../../../../../../class/power_cap
+      │   │   └──uevent
+      │   ├──intel-rapl:0:1
+      │   │   ├──constraint_0_name
+      │   │   ├──constraint_0_power_limit_uw
+      │   │   ├──constraint_0_time_window_us
+      │   │   ├──constraint_1_name
+      │   │   ├──constraint_1_power_limit_uw
+      │   │   ├──constraint_1_time_window_us
+      │   │   ├──device -> ../../intel-rapl:0
+      │   │   ├──energy_uj
+      │   │   ├──max_energy_range_uj
+      │   │   ├──name
+      │   │   ├──enabled
+      │   │   ├──power
+      │   │   │   ├──async
+      │   │   │   []
+      │   │   ├──subsystem -> ../../../../../../class/power_cap
+      │   │   └──uevent
+      │   ├──max_energy_range_uj
+      │   ├──max_power_range_uw
+      │   ├──name
+      │   ├──enabled
+      │   ├──power
+      │   │   ├──async
+      │   │   []
+      │   ├──subsystem -> ../../../../../class/power_cap
+      │   ├──enabled
+      │   ├──uevent
       ├──intel-rapl:1
-      │   ├──constraint_0_name
-      │   ├──constraint_0_power_limit_uw
-      │   ├──constraint_0_time_window_us
-      │   ├──constraint_1_name
-      │   ├──constraint_1_power_limit_uw
-      │   ├──constraint_1_time_window_us
-      │   ├──device -> ../../intel-rapl
-      │   ├──energy_uj
-      │   ├──intel-rapl:1:0
-      │   │   ├──constraint_0_name
-      │   │   ├──constraint_0_power_limit_uw
-      │   │   ├──constraint_0_time_window_us
-      │   │   ├──constraint_1_name
-      │   │   ├──constraint_1_power_limit_uw
-      │   │   ├──constraint_1_time_window_us
-      │   │   ├──device -> ../../intel-rapl:1
-      │   │   ├──energy_uj
-      │   │   ├──max_energy_range_uj
-      │   │   ├──name
-      │   │   ├──enabled
-      │   │   ├──power
-      │   │   │   ├──async
-      │   │   │   []
-      │   │   ├──subsystem -> ../../../../../../class/power_cap
-      │   │   └──uevent
-      │   ├──intel-rapl:1:1
-      │   │   ├──constraint_0_name
-      │   │   ├──constraint_0_power_limit_uw
-      │   │   ├──constraint_0_time_window_us
-      │   │   ├──constraint_1_name
-      │   │   ├──constraint_1_power_limit_uw
-      │   │   ├──constraint_1_time_window_us
-      │   │   ├──device -> ../../intel-rapl:1
-      │   │   ├──energy_uj
-      │   │   ├──max_energy_range_uj
-      │   │   ├──name
-      │   │   ├──enabled
-      │   │   ├──power
-      │   │   │   ├──async
-      │   │   │   []
-      │   │   ├──subsystem -> ../../../../../../class/power_cap
-      │   │   └──uevent
-      │   ├──max_energy_range_uj
-      │   ├──max_power_range_uw
-      │   ├──name
-      │   ├──enabled
-      │   ├──power
-      │   │   ├──async
-      │   │   []
-      │   ├──subsystem -> ../../../../../class/power_cap
-      │   ├──uevent
+      │   ├──constraint_0_name
+      │   ├──constraint_0_power_limit_uw
+      │   ├──constraint_0_time_window_us
+      │   ├──constraint_1_name
+      │   ├──constraint_1_power_limit_uw
+      │   ├──constraint_1_time_window_us
+      │   ├──device -> ../../intel-rapl
+      │   ├──energy_uj
+      │   ├──intel-rapl:1:0
+      │   │   ├──constraint_0_name
+      │   │   ├──constraint_0_power_limit_uw
+      │   │   ├──constraint_0_time_window_us
+      │   │   ├──constraint_1_name
+      │   │   ├──constraint_1_power_limit_uw
+      │   │   ├──constraint_1_time_window_us
+      │   │   ├──device -> ../../intel-rapl:1
+      │   │   ├──energy_uj
+      │   │   ├──max_energy_range_uj
+      │   │   ├──name
+      │   │   ├──enabled
+      │   │   ├──power
+      │   │   │   ├──async
+      │   │   │   []
+      │   │   ├──subsystem -> ../../../../../../class/power_cap
+      │   │   └──uevent
+      │   ├──intel-rapl:1:1
+      │   │   ├──constraint_0_name
+      │   │   ├──constraint_0_power_limit_uw
+      │   │   ├──constraint_0_time_window_us
+      │   │   ├──constraint_1_name
+      │   │   ├──constraint_1_power_limit_uw
+      │   │   ├──constraint_1_time_window_us
+      │   │   ├──device -> ../../intel-rapl:1
+      │   │   ├──energy_uj
+      │   │   ├──max_energy_range_uj
+      │   │   ├──name
+      │   │   ├──enabled
+      │   │   ├──power
+      │   │   │   ├──async
+      │   │   │   []
+      │   │   ├──subsystem -> ../../../../../../class/power_cap
+      │   │   └──uevent
+      │   ├──max_energy_range_uj
+      │   ├──max_power_range_uw
+      │   ├──name
+      │   ├──enabled
+      │   ├──power
+      │   │   ├──async
+      │   │   []
+      │   ├──subsystem -> ../../../../../class/power_cap
+      │   ├──uevent
       ├──power
-      │   ├──async
-      │   []
+      │   ├──async
+      │   []
       ├──subsystem -> ../../../../class/power_cap
       ├──enabled
       └──uevent
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 41/53] docs: ABI: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (45 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 13:53   ` Guenter Roeck
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Benson Leung,
	Enric Balletbo i Serra, Greg Kroah-Hartman, Guenter Roeck,
	Steven Price, Sudeep Holla, Suzuki K Poulose, Tom Rix,
	Vaibhav Jain, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH
	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar  | 2 +-
 Documentation/ABI/testing/sysfs-class-net-cdc_ncm             | 2 +-
 Documentation/ABI/testing/sysfs-devices-platform-ipmi         | 2 +-
 Documentation/ABI/testing/sysfs-devices-platform-trackpoint   | 2 +-
 Documentation/ABI/testing/sysfs-devices-soc                   | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar b/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
index 57a037791403..a7fb8f1169f2 100644
--- a/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
+++ b/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
@@ -29,7 +29,7 @@ KernelVersion:	4.2
 Description:
 		This allows you to control each LED segment. If the
 		lightbar is already running one of the automatic
-		sequences, you probably won’t see anything change because
+		sequences, you probably won't see anything change because
 		your color setting will be almost immediately replaced.
 		To get useful results, you should stop the lightbar
 		sequence first.
diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 06416d0e163d..41a1eef0d0e7 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 – 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-ipmi b/Documentation/ABI/testing/sysfs-devices-platform-ipmi
index 07df0ddc0b69..3935cdedea0e 100644
--- a/Documentation/ABI/testing/sysfs-devices-platform-ipmi
+++ b/Documentation/ABI/testing/sysfs-devices-platform-ipmi
@@ -52,7 +52,7 @@ Date:		Mar, 2006
 KernelVersion:	v2.6.17
 Contact:	openipmi-developer@lists.sourceforge.net
 Description:
-		(RO) Lists the IPMI ‘logical device’ commands and functions
+		(RO) Lists the IPMI 'logical device' commands and functions
 		that the controller supports that are in addition to the
 		mandatory IPM and Application commands.
 
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
index df11901a6b3d..82a38ac0435c 100644
--- a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
+++ b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
@@ -105,7 +105,7 @@ KernelVersion:	3.19
 Contact:	linux-input@vger.kernel.org
 Description:
 		(RW) This parameter controls the period of time to test for a
-		‘hands off’ condition (i.e. when no force is applied) before a
+		'hands off' condition (i.e. when no force is applied) before a
 		drift (noise) calibration occurs.
 
 		IBM Trackpoints have a feature to compensate for drift by
diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc
index ea999e292f11..7f90c6a44610 100644
--- a/Documentation/ABI/testing/sysfs-devices-soc
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@@ -27,11 +27,11 @@ Description:
 		(e.g. DB8500).
 
 		On many of ARM based silicon with SMCCC v1.2+ compliant firmware
-		this will contain the JEDEC JEP106 manufacturer’s identification
+		this will contain the JEDEC JEP106 manufacturer's identification
 		code. The format is "jep106:XXYY" where XX is identity code and
 		YY is continuation code.
 
-		This manufacturer’s identification code is defined by one
+		This manufacturer's identification code is defined by one
 		or more eight (8) bit fields, each consisting of seven (7)
 		data bits plus one (1) odd parity bit. It is a single field,
 		limiting the possible number of vendors to 126. To expand
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 42/53] docs: doc-guide: contributing.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (46 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/doc-guide/contributing.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index 67ee3691f91f..c2d709467c68 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 — a full four years.  Fixing
+present since that comment was added in 2016 - a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 43/53] docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (47 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  2021-05-10 10:37   ` Krzysztof Wilczyński
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Bjorn Helgaas,
	linux-kernel, linux-pci

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2013 ('–'): EN DASH
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/PCI/acpi-info.rst | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 060217081c79..9b4b04039982 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -22,9 +22,9 @@ or if the device has INTx interrupts connected by platform interrupt
 controllers and a _PRT is needed to describe those connections.
 
 ACPI resource description is done via _CRS objects of devices in the ACPI
-namespace [2].   The _CRS is like a generalized PCI BAR: the OS can read
+namespace [2].   The _CRS is like a generalized PCI BAR: the OS can read
 _CRS and figure out what resource is being consumed even if it doesn't have
-a driver for the device [3].  That's important because it means an old OS
+a driver for the device [3].  That's important because it means an old OS
 can work correctly even on a system with new devices unknown to the OS.
 The new devices might not do anything, but the OS can at least make sure no
 resources conflict with them.
@@ -41,15 +41,15 @@ ACPI, that device will have a specific _HID/_CID that tells the OS what
 driver to bind to it, and the _CRS tells the OS and the driver where the
 device's registers are.
 
-PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should
-describe all the address space they consume.  This includes all the windows
+PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should
+describe all the address space they consume.  This includes all the windows
 they forward down to the PCI bus, as well as registers of the host bridge
-itself that are not forwarded to PCI.  The host bridge registers include
+itself that are not forwarded to PCI.  The host bridge registers include
 things like secondary/subordinate bus registers that determine the bus
 range below the bridge, window registers that describe the apertures, etc.
 These are all device-specific, non-architected things, so the only way a
 PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
-the device-specific details.  The host bridge registers also include ECAM
+the device-specific details.  The host bridge registers also include ECAM
 space, since it is consumed by the host bridge.
 
 ACPI defines a Consumer/Producer bit to distinguish the bridge registers
@@ -66,7 +66,7 @@ the PNP0A03/PNP0A08 device itself.  The workaround was to describe the
 bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
 With the exception of ECAM, the bridge register space is device-specific
 anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
-know about it.  
+know about it.  
 
 New architectures should be able to use "Consumer" Extended Address Space
 descriptors in the PNP0A03 device for bridge registers, including ECAM,
@@ -75,9 +75,9 @@ ia64 kernels assume all address space descriptors, including "Consumer"
 Extended Address Space ones, are windows, so it would not be safe to
 describe bridge registers this way on those architectures.
 
-PNP0C02 "motherboard" devices are basically a catch-all.  There's no
+PNP0C02 "motherboard" devices are basically a catch-all.  There's no
 programming model for them other than "don't use these resources for
-anything else."  So a PNP0C02 _CRS should claim any address space that is
+anything else."  So a PNP0C02 _CRS should claim any address space that is
 (1) not claimed by _CRS under any other device object in the ACPI namespace
 and (2) should not be assigned by the OS to something else.
 
@@ -125,7 +125,7 @@ address always corresponds to bus 0, even if the bus range below the bridge
     requirements of the device.  It may also call _CRS to find the current
     resource settings for the device.  Using this information, the Plug and
     Play system determines what resources the device should consume and
-    sets those resources by calling the device’s _SRS control method.
+    sets those resources by calling the device's _SRS control method.
 
     In ACPI, devices can consume resources (for example, legacy keyboards),
     provide resources (for example, a proprietary PCI bridge), or do both.
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 – This device consumes this resource
-        * 0 – This device produces and consumes this resource
+        * 1 - This device consumes this resource
+        * 0 - This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
@@ -156,7 +156,7 @@ address always corresponds to bus 0, even if the bus range below the bridge
     4.1.3) must be reserved by declaring a motherboard resource.  For most
     systems, the motherboard resource would appear at the root of the ACPI
     namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
-    the resources in this case should not be claimed in the root PCI bus’s
+    the resources in this case should not be claimed in the root PCI bus's
     _CRS.  The resources can optionally be returned in Int15 E820 or
     EFIGetMemoryMap as reserved memory but must always be reported through
     ACPI as a motherboard resource.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
  (?)
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Mali DP Maintainers, James (Qian) Wang,
	Jonathan Corbet, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Liviu Dudau, Maarten Lankhorst, Maxime Ripard,
	Mihail Atanassov, Rodrigo Vivi, Thomas Zimmermann, dri-devel,
	intel-gfx, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/gpu/i915.rst       | 2 +-
 Documentation/gpu/komeda-kms.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..2cbf54460b48 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -361,7 +361,7 @@ Locking Guidelines
 	  real bad.
 
 #. Do not nest different lru/memory manager locks within each other.
-   Take them in turn to update memory allocations, relying on the object’s
+   Take them in turn to update memory allocations, relying on the object's
    dma_resv ww_mutex to serialize against other operations.
 
 #. The suggestion for lru/memory managers locks is that they are small
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d..c2067678e92c 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -324,7 +324,7 @@ the control-abilites of device.
 
 We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
 pipelines. Since komeda is not for D71 only but also intended for later products,
-of course we’d better share as much as possible between different products. To
+of course we'd better share as much as possible between different products. To
 achieve this, split the komeda device into two layers: CORE and CHIP.
 
 -   CORE: for common features and capabilities handling.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Thomas Zimmermann, Jonathan Corbet, Mauro Carvalho Chehab,
	dri-devel, Liviu Dudau, linux-kernel, David Airlie,
	James (Qian) Wang, Rodrigo Vivi, Mali DP Maintainers,
	Mihail Atanassov, intel-gfx

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/gpu/i915.rst       | 2 +-
 Documentation/gpu/komeda-kms.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..2cbf54460b48 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -361,7 +361,7 @@ Locking Guidelines
 	  real bad.
 
 #. Do not nest different lru/memory manager locks within each other.
-   Take them in turn to update memory allocations, relying on the object’s
+   Take them in turn to update memory allocations, relying on the object's
    dma_resv ww_mutex to serialize against other operations.
 
 #. The suggestion for lru/memory managers locks is that they are small
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d..c2067678e92c 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -324,7 +324,7 @@ the control-abilites of device.
 
 We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
 pipelines. Since komeda is not for D71 only but also intended for later products,
-of course we’d better share as much as possible between different products. To
+of course we'd better share as much as possible between different products. To
 achieve this, split the komeda device into two layers: CORE and CHIP.
 
 -   CORE: for common features and capabilities handling.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [Intel-gfx] [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Thomas Zimmermann, Jonathan Corbet, Mauro Carvalho Chehab,
	dri-devel, linux-kernel, David Airlie, James (Qian) Wang,
	Maxime Ripard, Mali DP Maintainers, Mihail Atanassov, intel-gfx

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/gpu/i915.rst       | 2 +-
 Documentation/gpu/komeda-kms.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..2cbf54460b48 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -361,7 +361,7 @@ Locking Guidelines
 	  real bad.
 
 #. Do not nest different lru/memory manager locks within each other.
-   Take them in turn to update memory allocations, relying on the object’s
+   Take them in turn to update memory allocations, relying on the object's
    dma_resv ww_mutex to serialize against other operations.
 
 #. The suggestion for lru/memory managers locks is that they are small
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d..c2067678e92c 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -324,7 +324,7 @@ the control-abilites of device.
 
 We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
 pipelines. Since komeda is not for D71 only but also intended for later products,
-of course we’d better share as much as possible between different products. To
+of course we'd better share as much as possible between different products. To
 achieve this, split the komeda device into two layers: CORE and CHIP.
 
 -   CORE: for common features and capabilities handling.
-- 
2.30.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 45/53] docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet,
	Nícolas F. R. A. Prado, Jaroslav Kysela, Julia Lawall,
	Takashi Iwai, alsa-devel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../kernel-api/writing-an-alsa-driver.rst     | 68 +++++++++----------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index e6365836fa8b..201ced3bba6e 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -533,7 +533,7 @@ Management of Cards and Components
 Card Instance
 -------------
 
-For each soundcard, a “card” record must be allocated.
+For each soundcard, a "card" record must be allocated.
 
 A card record is the headquarters of the soundcard. It manages the whole
 list of devices (components) on the soundcard, such as PCM, mixers,
@@ -980,7 +980,7 @@ The role of destructor is simple: disable the hardware (if already
 activated) and release the resources. So far, we have no hardware part,
 so the disabling code is not written here.
 
-To release the resources, the “check-and-release” method is a safer way.
+To release the resources, the "check-and-release" method is a safer way.
 For the interrupt, do like this:
 
 ::
@@ -1133,7 +1133,7 @@ record:
 
 The ``probe`` and ``remove`` functions have already been defined in
 the previous sections. The ``name`` field is the name string of this
-device. Note that you must not use a slash “/” in this string.
+device. Note that you must not use a slash "/" in this string.
 
 And at last, the module entries:
 
@@ -1692,8 +1692,8 @@ Typically, you'll have a hardware descriptor as below:
 
    The other possible flags are ``SNDRV_PCM_INFO_PAUSE`` and
    ``SNDRV_PCM_INFO_RESUME``. The ``PAUSE`` bit means that the pcm
-   supports the “pause” operation, while the ``RESUME`` bit means that
-   the pcm supports the full “suspend/resume” operation. If the
+   supports the "pause" operation, while the ``RESUME`` bit means that
+   the pcm supports the full "suspend/resume" operation. If the
    ``PAUSE`` flag is set, the ``trigger`` callback below must handle
    the corresponding (pause push/release) commands. The suspend/resume
    trigger commands can be defined even without the ``RESUME``
@@ -1731,7 +1731,7 @@ Typically, you'll have a hardware descriptor as below:
    ``periods_min`` define the maximum and minimum number of periods in
    the buffer.
 
-   The “period” is a term that corresponds to a fragment in the OSS
+   The "period" is a term that corresponds to a fragment in the OSS
    world. The period defines the size at which a PCM interrupt is
    generated. This size strongly depends on the hardware. Generally,
    the smaller period size will give you more interrupts, that is,
@@ -1756,7 +1756,7 @@ application. This field contains the enum value
 ``SNDRV_PCM_FORMAT_XXX``.
 
 One thing to be noted is that the configured buffer and period sizes
-are stored in “frames” in the runtime. In the ALSA world, ``1 frame =
+are stored in "frames" in the runtime. In the ALSA world, ``1 frame =
 channels \* samples-size``. For conversion between frames and bytes,
 you can use the :c:func:`frames_to_bytes()` and
 :c:func:`bytes_to_frames()` helper functions.
@@ -1999,7 +1999,7 @@ prepare callback
 
   static int snd_xxx_prepare(struct snd_pcm_substream *substream);
 
-This callback is called when the pcm is “prepared”. You can set the
+This callback is called when the pcm is "prepared". You can set the
 format type, sample rate, etc. here. The difference from ``hw_params``
 is that the ``prepare`` callback will be called each time
 :c:func:`snd_pcm_prepare()` is called, i.e. when recovering after
@@ -2436,8 +2436,8 @@ size is aligned with the period size.
 
 The hw constraint is a very much powerful mechanism to define the
 preferred PCM configuration, and there are relevant helpers.
-I won't give more details here, rather I would like to say, “Luke, use
-the source.”
+I won't give more details here, rather I would like to say, "Luke, use
+the source."
 
 Control Interface
 =================
@@ -2518,50 +2518,50 @@ Control Names
 -------------
 
 There are some standards to define the control names. A control is
-usually defined from the three parts as “SOURCE DIRECTION FUNCTION”.
+usually defined from the three parts as "SOURCE DIRECTION FUNCTION".
 
 The first, ``SOURCE``, specifies the source of the control, and is a
-string such as “Master”, “PCM”, “CD” and “Line”. There are many
+string such as "Master", "PCM", "CD" and "Line". There are many
 pre-defined sources.
 
 The second, ``DIRECTION``, is one of the following strings according to
-the direction of the control: “Playback”, “Capture”, “Bypass Playback”
-and “Bypass Capture”. Or, it can be omitted, meaning both playback and
+the direction of the control: "Playback", "Capture", "Bypass Playback"
+and "Bypass Capture". Or, it can be omitted, meaning both playback and
 capture directions.
 
 The third, ``FUNCTION``, is one of the following strings according to
-the function of the control: “Switch”, “Volume” and “Route”.
+the function of the control: "Switch", "Volume" and "Route".
 
-The example of control names are, thus, “Master Capture Switch” or “PCM
-Playback Volume”.
+The example of control names are, thus, "Master Capture Switch" or "PCM
+Playback Volume".
 
 There are some exceptions:
 
 Global capture and playback
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-“Capture Source”, “Capture Switch” and “Capture Volume” are used for the
-global capture (input) source, switch and volume. Similarly, “Playback
-Switch” and “Playback Volume” are used for the global output gain switch
+"Capture Source", "Capture Switch" and "Capture Volume" are used for the
+global capture (input) source, switch and volume. Similarly, "Playback
+Switch" and "Playback Volume" are used for the global output gain switch
 and volume.
 
 Tone-controls
 ~~~~~~~~~~~~~
 
-tone-control switch and volumes are specified like “Tone Control - XXX”,
-e.g. “Tone Control - Switch”, “Tone Control - Bass”, “Tone Control -
-Center”.
+tone-control switch and volumes are specified like "Tone Control - XXX",
+e.g. "Tone Control - Switch", "Tone Control - Bass", "Tone Control -
+Center".
 
 3D controls
 ~~~~~~~~~~~
 
-3D-control switches and volumes are specified like “3D Control - XXX”,
-e.g. “3D Control - Switch”, “3D Control - Center”, “3D Control - Space”.
+3D-control switches and volumes are specified like "3D Control - XXX",
+e.g. "3D Control - Switch", "3D Control - Center", "3D Control - Space".
 
 Mic boost
 ~~~~~~~~~
 
-Mic-boost switch is set as “Mic Boost” or “Mic Boost (6dB)”.
+Mic-boost switch is set as "Mic Boost" or "Mic Boost (6dB)".
 
 More precise information can be found in
 ``Documentation/sound/designs/control-names.rst``.
@@ -3368,7 +3368,7 @@ This ensures that the device can be closed and the driver unloaded
 without losing data.
 
 This callback is optional. If you do not set ``drain`` in the struct
-snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds
+snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds
 instead.
 
 Miscellaneous Devices
@@ -3506,20 +3506,20 @@ fixed as 4 bytes array (value.iec958.status[x]). For the ``info``
 callback, you don't specify the value field for this type (the count
 field must be set, though).
 
-“IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958
-status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask”
+"IEC958 Playback Con Mask" is used to return the bit-mask for the IEC958
+status bits of consumer mode. Similarly, "IEC958 Playback Pro Mask"
 returns the bitmask for professional mode. They are read-only controls,
 and are defined as MIXER controls (iface =
 ``SNDRV_CTL_ELEM_IFACE_MIXER``).
 
-Meanwhile, “IEC958 Playback Default” control is defined for getting and
+Meanwhile, "IEC958 Playback Default" control is defined for getting and
 setting the current default IEC958 bits. Note that this one is usually
 defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``),
 although in some places it's defined as a MIXER control.
 
 In addition, you can define the control switches to enable/disable or to
 set the raw bit mode. The implementation will depend on the chip, but
-the control should be named as “IEC958 xxx”, preferably using the
+the control should be named as "IEC958 xxx", preferably using the
 :c:func:`SNDRV_CTL_NAME_IEC958()` macro.
 
 You can find several cases, for example, ``pci/emu10k1``,
@@ -3547,7 +3547,7 @@ function.
 
 Usually, ALSA drivers try to allocate and reserve a large contiguous
 physical space at the time the module is loaded for the later use. This
-is called “pre-allocation”. As already written, you can call the
+is called "pre-allocation". As already written, you can call the
 following function at pcm instance construction time (in the case of PCI
 bus).
 
@@ -4163,7 +4163,7 @@ The typical coding would be like below:
 
 Also, don't forget to define the module description and the license.
 Especially, the recent modprobe requires to define the
-module license as GPL, etc., otherwise the system is shown as “tainted”.
+module license as GPL, etc., otherwise the system is shown as "tainted".
 
 ::
 
@@ -4181,7 +4181,7 @@ So far, you've learned how to write the driver codes. And you might have
 a question now: how to put my own driver into the ALSA driver tree? Here
 (finally :) the standard procedure is described briefly.
 
-Suppose that you create a new PCI driver for the card “xyz”. The card
+Suppose that you create a new PCI driver for the card "xyz". The card
 module name would be snd-xyz. The new driver is usually put into the
 alsa-driver tree, ``sound/pci`` directory in the case of PCI
 cards.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 45/53] docs: sound: kernel-api: writing-an-alsa-driver.rst: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: alsa-devel, Jonathan Corbet, Mauro Carvalho Chehab, linux-kernel,
	Takashi Iwai, Julia Lawall, Nícolas F. R. A. Prado

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../kernel-api/writing-an-alsa-driver.rst     | 68 +++++++++----------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index e6365836fa8b..201ced3bba6e 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -533,7 +533,7 @@ Management of Cards and Components
 Card Instance
 -------------
 
-For each soundcard, a “card” record must be allocated.
+For each soundcard, a "card" record must be allocated.
 
 A card record is the headquarters of the soundcard. It manages the whole
 list of devices (components) on the soundcard, such as PCM, mixers,
@@ -980,7 +980,7 @@ The role of destructor is simple: disable the hardware (if already
 activated) and release the resources. So far, we have no hardware part,
 so the disabling code is not written here.
 
-To release the resources, the “check-and-release” method is a safer way.
+To release the resources, the "check-and-release" method is a safer way.
 For the interrupt, do like this:
 
 ::
@@ -1133,7 +1133,7 @@ record:
 
 The ``probe`` and ``remove`` functions have already been defined in
 the previous sections. The ``name`` field is the name string of this
-device. Note that you must not use a slash “/” in this string.
+device. Note that you must not use a slash "/" in this string.
 
 And at last, the module entries:
 
@@ -1692,8 +1692,8 @@ Typically, you'll have a hardware descriptor as below:
 
    The other possible flags are ``SNDRV_PCM_INFO_PAUSE`` and
    ``SNDRV_PCM_INFO_RESUME``. The ``PAUSE`` bit means that the pcm
-   supports the “pause” operation, while the ``RESUME`` bit means that
-   the pcm supports the full “suspend/resume” operation. If the
+   supports the "pause" operation, while the ``RESUME`` bit means that
+   the pcm supports the full "suspend/resume" operation. If the
    ``PAUSE`` flag is set, the ``trigger`` callback below must handle
    the corresponding (pause push/release) commands. The suspend/resume
    trigger commands can be defined even without the ``RESUME``
@@ -1731,7 +1731,7 @@ Typically, you'll have a hardware descriptor as below:
    ``periods_min`` define the maximum and minimum number of periods in
    the buffer.
 
-   The “period” is a term that corresponds to a fragment in the OSS
+   The "period" is a term that corresponds to a fragment in the OSS
    world. The period defines the size at which a PCM interrupt is
    generated. This size strongly depends on the hardware. Generally,
    the smaller period size will give you more interrupts, that is,
@@ -1756,7 +1756,7 @@ application. This field contains the enum value
 ``SNDRV_PCM_FORMAT_XXX``.
 
 One thing to be noted is that the configured buffer and period sizes
-are stored in “frames” in the runtime. In the ALSA world, ``1 frame =
+are stored in "frames" in the runtime. In the ALSA world, ``1 frame =
 channels \* samples-size``. For conversion between frames and bytes,
 you can use the :c:func:`frames_to_bytes()` and
 :c:func:`bytes_to_frames()` helper functions.
@@ -1999,7 +1999,7 @@ prepare callback
 
   static int snd_xxx_prepare(struct snd_pcm_substream *substream);
 
-This callback is called when the pcm is “prepared”. You can set the
+This callback is called when the pcm is "prepared". You can set the
 format type, sample rate, etc. here. The difference from ``hw_params``
 is that the ``prepare`` callback will be called each time
 :c:func:`snd_pcm_prepare()` is called, i.e. when recovering after
@@ -2436,8 +2436,8 @@ size is aligned with the period size.
 
 The hw constraint is a very much powerful mechanism to define the
 preferred PCM configuration, and there are relevant helpers.
-I won't give more details here, rather I would like to say, “Luke, use
-the source.”
+I won't give more details here, rather I would like to say, "Luke, use
+the source."
 
 Control Interface
 =================
@@ -2518,50 +2518,50 @@ Control Names
 -------------
 
 There are some standards to define the control names. A control is
-usually defined from the three parts as “SOURCE DIRECTION FUNCTION”.
+usually defined from the three parts as "SOURCE DIRECTION FUNCTION".
 
 The first, ``SOURCE``, specifies the source of the control, and is a
-string such as “Master”, “PCM”, “CD” and “Line”. There are many
+string such as "Master", "PCM", "CD" and "Line". There are many
 pre-defined sources.
 
 The second, ``DIRECTION``, is one of the following strings according to
-the direction of the control: “Playback”, “Capture”, “Bypass Playback”
-and “Bypass Capture”. Or, it can be omitted, meaning both playback and
+the direction of the control: "Playback", "Capture", "Bypass Playback"
+and "Bypass Capture". Or, it can be omitted, meaning both playback and
 capture directions.
 
 The third, ``FUNCTION``, is one of the following strings according to
-the function of the control: “Switch”, “Volume” and “Route”.
+the function of the control: "Switch", "Volume" and "Route".
 
-The example of control names are, thus, “Master Capture Switch” or “PCM
-Playback Volume”.
+The example of control names are, thus, "Master Capture Switch" or "PCM
+Playback Volume".
 
 There are some exceptions:
 
 Global capture and playback
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-“Capture Source”, “Capture Switch” and “Capture Volume” are used for the
-global capture (input) source, switch and volume. Similarly, “Playback
-Switch” and “Playback Volume” are used for the global output gain switch
+"Capture Source", "Capture Switch" and "Capture Volume" are used for the
+global capture (input) source, switch and volume. Similarly, "Playback
+Switch" and "Playback Volume" are used for the global output gain switch
 and volume.
 
 Tone-controls
 ~~~~~~~~~~~~~
 
-tone-control switch and volumes are specified like “Tone Control - XXX”,
-e.g. “Tone Control - Switch”, “Tone Control - Bass”, “Tone Control -
-Center”.
+tone-control switch and volumes are specified like "Tone Control - XXX",
+e.g. "Tone Control - Switch", "Tone Control - Bass", "Tone Control -
+Center".
 
 3D controls
 ~~~~~~~~~~~
 
-3D-control switches and volumes are specified like “3D Control - XXX”,
-e.g. “3D Control - Switch”, “3D Control - Center”, “3D Control - Space”.
+3D-control switches and volumes are specified like "3D Control - XXX",
+e.g. "3D Control - Switch", "3D Control - Center", "3D Control - Space".
 
 Mic boost
 ~~~~~~~~~
 
-Mic-boost switch is set as “Mic Boost” or “Mic Boost (6dB)”.
+Mic-boost switch is set as "Mic Boost" or "Mic Boost (6dB)".
 
 More precise information can be found in
 ``Documentation/sound/designs/control-names.rst``.
@@ -3368,7 +3368,7 @@ This ensures that the device can be closed and the driver unloaded
 without losing data.
 
 This callback is optional. If you do not set ``drain`` in the struct
-snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds
+snd_rawmidi_ops structure, ALSA will simply wait for 50 milliseconds
 instead.
 
 Miscellaneous Devices
@@ -3506,20 +3506,20 @@ fixed as 4 bytes array (value.iec958.status[x]). For the ``info``
 callback, you don't specify the value field for this type (the count
 field must be set, though).
 
-“IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958
-status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask”
+"IEC958 Playback Con Mask" is used to return the bit-mask for the IEC958
+status bits of consumer mode. Similarly, "IEC958 Playback Pro Mask"
 returns the bitmask for professional mode. They are read-only controls,
 and are defined as MIXER controls (iface =
 ``SNDRV_CTL_ELEM_IFACE_MIXER``).
 
-Meanwhile, “IEC958 Playback Default” control is defined for getting and
+Meanwhile, "IEC958 Playback Default" control is defined for getting and
 setting the current default IEC958 bits. Note that this one is usually
 defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``),
 although in some places it's defined as a MIXER control.
 
 In addition, you can define the control switches to enable/disable or to
 set the raw bit mode. The implementation will depend on the chip, but
-the control should be named as “IEC958 xxx”, preferably using the
+the control should be named as "IEC958 xxx", preferably using the
 :c:func:`SNDRV_CTL_NAME_IEC958()` macro.
 
 You can find several cases, for example, ``pci/emu10k1``,
@@ -3547,7 +3547,7 @@ function.
 
 Usually, ALSA drivers try to allocate and reserve a large contiguous
 physical space at the time the module is loaded for the later use. This
-is called “pre-allocation”. As already written, you can call the
+is called "pre-allocation". As already written, you can call the
 following function at pcm instance construction time (in the case of PCI
 bus).
 
@@ -4163,7 +4163,7 @@ The typical coding would be like below:
 
 Also, don't forget to define the module description and the license.
 Especially, the recent modprobe requires to define the
-module license as GPL, etc., otherwise the system is shown as “tainted”.
+module license as GPL, etc., otherwise the system is shown as "tainted".
 
 ::
 
@@ -4181,7 +4181,7 @@ So far, you've learned how to write the driver codes. And you might have
 a question now: how to put my own driver into the ALSA driver tree? Here
 (finally :) the standard procedure is described briefly.
 
-Suppose that you create a new PCI driver for the card “xyz”. The card
+Suppose that you create a new PCI driver for the card "xyz". The card
 module name would be snd-xyz. The new driver is usually put into the
 alsa-driver tree, ``sound/pci`` directory in the case of PCI
 cards.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 46/53] docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Catalin Marinas,
	Will Deacon, linux-arm-kernel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/arm64/arm-acpi.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst
index 47ecb9930dde..ceb109ff82aa 100644
--- a/Documentation/arm64/arm-acpi.rst
+++ b/Documentation/arm64/arm-acpi.rst
@@ -36,12 +36,12 @@ of the summary text almost directly, to be honest.
 
 The short form of the rationale for ACPI on ARM is:
 
--  ACPI’s byte code (AML) allows the platform to encode hardware behavior,
+-  ACPI's byte code (AML) allows the platform to encode hardware behavior,
    while DT explicitly does not support this.  For hardware vendors, being
    able to encode behavior is a key tool used in supporting operating
    system releases on new hardware.
 
--  ACPI’s OSPM defines a power management model that constrains what the
+-  ACPI's OSPM defines a power management model that constrains what the
    platform is allowed to do into a specific model, while still providing
    flexibility in hardware design.
 
@@ -69,7 +69,7 @@ Key to the use of ACPI is the support model.  For servers in general, the
 responsibility for hardware behaviour cannot solely be the domain of the
 kernel, but rather must be split between the platform and the kernel, in
 order to allow for orderly change over time.  ACPI frees the OS from needing
-to understand all the minute details of the hardware so that the OS doesn’t
+to understand all the minute details of the hardware so that the OS doesn't
 need to be ported to each and every device individually.  It allows the
 hardware vendors to take responsibility for power management behaviour without
 depending on an OS release cycle which is not under their control.
@@ -81,7 +81,7 @@ in place.  DT does exactly what Linux needs it to when working with vertically
 integrated devices, but there are no good processes for supporting what the
 server vendors need.  Linux could potentially get there with DT, but doing so
 really just duplicates something that already works.  ACPI already does what
-the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
+the hardware vendors need, Microsoft won't collaborate on DT, and hardware
 vendors would still end up providing two completely separate firmware
 interfaces -- one for Linux and one for Windows.
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 46/53] docs: arm64: arm-acpi.rst: avoid using UTF-8 chars
@ 2021-05-10 10:26   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Catalin Marinas,
	Will Deacon, linux-arm-kernel, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/arm64/arm-acpi.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst
index 47ecb9930dde..ceb109ff82aa 100644
--- a/Documentation/arm64/arm-acpi.rst
+++ b/Documentation/arm64/arm-acpi.rst
@@ -36,12 +36,12 @@ of the summary text almost directly, to be honest.
 
 The short form of the rationale for ACPI on ARM is:
 
--  ACPI’s byte code (AML) allows the platform to encode hardware behavior,
+-  ACPI's byte code (AML) allows the platform to encode hardware behavior,
    while DT explicitly does not support this.  For hardware vendors, being
    able to encode behavior is a key tool used in supporting operating
    system releases on new hardware.
 
--  ACPI’s OSPM defines a power management model that constrains what the
+-  ACPI's OSPM defines a power management model that constrains what the
    platform is allowed to do into a specific model, while still providing
    flexibility in hardware design.
 
@@ -69,7 +69,7 @@ Key to the use of ACPI is the support model.  For servers in general, the
 responsibility for hardware behaviour cannot solely be the domain of the
 kernel, but rather must be split between the platform and the kernel, in
 order to allow for orderly change over time.  ACPI frees the OS from needing
-to understand all the minute details of the hardware so that the OS doesn’t
+to understand all the minute details of the hardware so that the OS doesn't
 need to be ported to each and every device individually.  It allows the
 hardware vendors to take responsibility for power management behaviour without
 depending on an OS release cycle which is not under their control.
@@ -81,7 +81,7 @@ in place.  DT does exactly what Linux needs it to when working with vertically
 integrated devices, but there are no good processes for supporting what the
 server vendors need.  Linux could potentially get there with DT, but doing so
 really just duplicates something that already works.  ACPI already does what
-the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
+the hardware vendors need, Microsoft won't collaborate on DT, and hardware
 vendors would still end up providing two completely separate firmware
 interfaces -- one for Linux and one for Windows.
 
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 47/53] docs: infiniband: tag_matching.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (51 preceding siblings ...)
  (?)
@ 2021-05-10 10:26 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:26 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Doug Ledford,
	Jason Gunthorpe, linux-kernel, linux-rdma

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2013 ('–'): EN DASH
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/infiniband/tag_matching.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index ef56ea585f92..b89528a31d10 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,15 +8,15 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank – wild car may be specified by the receiver
-*	Destination rank – wild
+*	Source rank - wild car may be specified by the receiver
+*	Destination rank - wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
 and the earliest posted-receive is the pair that must be used to satisfy the
-matching operation. However, this doesn’t imply that tags are consumed in
+matching operation. However, this doesn't imply that tags are consumed in
 the order they are created, e.g., a later generated tag may be consumed, if
-earlier tags can’t be used to satisfy the matching rules.
+earlier tags can't be used to satisfy the matching rules.
 
 When a message is sent from the sender to the receiver, the communication
 library may attempt to process the operation either after or before the
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 48/53] docs: timers: no_hz.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (52 preceding siblings ...)
  (?)
@ 2021-05-10 10:27 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:27 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Thomas Gleixner, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/timers/no_hz.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/timers/no_hz.rst b/Documentation/timers/no_hz.rst
index c4c70e1aada3..6cadad7c3aad 100644
--- a/Documentation/timers/no_hz.rst
+++ b/Documentation/timers/no_hz.rst
@@ -1,4 +1,4 @@
-======================================
+======================================
 NO_HZ: Reducing Scheduling-Clock Ticks
 ======================================
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 49/53] docs: misc-devices: ibmvmc.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (53 preceding siblings ...)
  (?)
@ 2021-05-10 10:27 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:27 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/misc-devices/ibmvmc.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/misc-devices/ibmvmc.rst b/Documentation/misc-devices/ibmvmc.rst
index b46df4ea2b81..b075211c6dce 100644
--- a/Documentation/misc-devices/ibmvmc.rst
+++ b/Documentation/misc-devices/ibmvmc.rst
@@ -36,7 +36,7 @@ Management Application
 ----------------------
 
 In the management partition, a management application exists which enables
-a system administrator to configure the system’s partitioning
+a system administrator to configure the system's partitioning
 characteristics via a command line interface (CLI) or Representational
 State Transfer Application (REST API's).
 
@@ -108,7 +108,7 @@ This section provides an example for the management application
 implementation where a device driver is used to interface to the VMC
 device. This driver consists of a new device, for example /dev/ibmvmc,
 which provides interfaces to open, close, read, write, and perform
-ioctl’s against the VMC device.
+ioctl's against the VMC device.
 
 VMC Interface Initialization
 ----------------------------
@@ -177,14 +177,14 @@ VMC Interface Runtime
 During normal runtime, the management application and the hypervisor
 exchange HMC messages via the Signal VMC message and RDMA operations. When
 sending data to the hypervisor, the management application performs a
-write() to the VMC device, and the driver RDMA’s the data to the hypervisor
+write() to the VMC device, and the driver RDMA's the data to the hypervisor
 and then sends a Signal Message. If a write() is attempted before VMC
 device buffers have been made available by the hypervisor, or no buffers
 are currently available, EBUSY is returned in response to the write(). A
 write() will return EIO for all other errors, such as an invalid device
 state. When the hypervisor sends a message to the management, the data is
 put into a VMC buffer and an Signal Message is sent to the VMC driver in
-the management partition. The driver RDMA’s the buffer into the partition
+the management partition. The driver RDMA's the buffer into the partition
 and passes the data up to the appropriate management application via a
 read() to the VMC device. The read() request blocks if there is no buffer
 available to read. The management application may use select() to wait for
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 50/53] docs: firmware-guide: acpi: lpit.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (54 preceding siblings ...)
  (?)
@ 2021-05-10 10:27 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:27 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Rafael J. Wysocki,
	Len Brown, linux-acpi, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/firmware-guide/acpi/lpit.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/firmware-guide/acpi/lpit.rst b/Documentation/firmware-guide/acpi/lpit.rst
index 37922a903573..d7d6c406074a 100644
--- a/Documentation/firmware-guide/acpi/lpit.rst
+++ b/Documentation/firmware-guide/acpi/lpit.rst
@@ -5,7 +5,7 @@ Low Power Idle Table (LPIT)
 ===========================
 
 To enumerate platform Low Power Idle states, Intel platforms are using
-“Low Power Idle Table” (LPIT). More details about this table can be
+"Low Power Idle Table" (LPIT). More details about this table can be
 downloaded from:
 https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 51/53] docs: firmware-guide: acpi: dsd: graph.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (55 preceding siblings ...)
  (?)
@ 2021-05-10 10:27 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:27 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Alexander A. Klimov, Jonathan Corbet,
	Rafael J. Wysocki, Len Brown, Sakari Ailus, Vishal Verma,
	linux-acpi, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/firmware-guide/acpi/dsd/graph.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst
index 7072db801aeb..954b99ec6b77 100644
--- a/Documentation/firmware-guide/acpi/dsd/graph.rst
+++ b/Documentation/firmware-guide/acpi/dsd/graph.rst
@@ -159,7 +159,7 @@ References
 
 [2] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
 
-[3] Documentation/devicetree/bindings/graph.txt
+[3] Documentation/devicetree/bindings/graph.txt
 
 [4] Device Properties UUID For _DSD.
     https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 52/53] docs: virt: kvm: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (56 preceding siblings ...)
  (?)
@ 2021-05-10 10:27 ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:27 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet, Paolo Bonzini, kvm, linux-kernel

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 Documentation/virt/kvm/api.rst                | 28 +++++++++----------
 .../virt/kvm/running-nested-guests.rst        | 12 ++++----
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 22d077562149..295daf6178f8 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -850,7 +850,7 @@ in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
 use PPIs designated for specific cpus.  The irq field is interpreted
 like this::
 
-  bits:  |  31 ... 28  | 27 ... 24 | 23  ... 16 | 15 ... 0 |
+  bits:  |  31 ... 28  | 27 ... 24 | 23  ... 16 | 15 ... 0 |
   field: | vcpu2_index | irq_type  | vcpu_index |  irq_id  |
 
 The irq_type field has the following values:
@@ -2144,10 +2144,10 @@ prior to calling the KVM_RUN ioctl.
 Errors:
 
   ======   ============================================================
-  ENOENT   no such register
-  EINVAL   invalid register ID, or no such register or used with VMs in
+  ENOENT   no such register
+  EINVAL   invalid register ID, or no such register or used with VMs in
            protected virtualization mode on s390
-  EPERM    (arm64) register access not allowed before vcpu finalization
+  EPERM    (arm64) register access not allowed before vcpu finalization
   ======   ============================================================
 
 (These error codes are indicative only: do not rely on a specific error
@@ -2585,10 +2585,10 @@ following id bit patterns::
 Errors include:
 
   ======== ============================================================
-  ENOENT   no such register
-  EINVAL   invalid register ID, or no such register or used with VMs in
+  ENOENT   no such register
+  EINVAL   invalid register ID, or no such register or used with VMs in
            protected virtualization mode on s390
-  EPERM    (arm64) register access not allowed before vcpu finalization
+  EPERM    (arm64) register access not allowed before vcpu finalization
   ======== ============================================================
 
 (These error codes are indicative only: do not rely on a specific error
@@ -3107,13 +3107,13 @@ current state.  "addr" is ignored.
 Errors:
 
   ======     =================================================================
-  EINVAL     the target is unknown, or the combination of features is invalid.
-  ENOENT     a features bit specified is unknown.
+  EINVAL     the target is unknown, or the combination of features is invalid.
+  ENOENT     a features bit specified is unknown.
   ======     =================================================================
 
 This tells KVM what type of CPU to present to the guest, and what
-optional features it should have.  This will cause a reset of the cpu
-registers to their initial values.  If this is not called, KVM_RUN will
+optional features it should have.  This will cause a reset of the cpu
+registers to their initial values.  If this is not called, KVM_RUN will
 return ENOEXEC for that vcpu.
 
 The initial values are defined as:
@@ -3234,8 +3234,8 @@ VCPU matching underlying host.
 Errors:
 
   =====      ==============================================================
-  E2BIG      the reg index list is too big to fit in the array specified by
-             the user (the number required will be written into n).
+  E2BIG      the reg index list is too big to fit in the array specified by
+             the user (the number required will be written into n).
   =====      ==============================================================
 
 ::
@@ -3283,7 +3283,7 @@ specific device.
 ARM/arm64 divides the id field into two parts, a device id and an
 address type id specific to the individual device::
 
-  bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
+  bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
   field: |        0x00000000      |     device id   |  addr type id  |
 
 ARM/arm64 currently only require this when using the in-kernel GIC
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index bd70c69468ae..e9dff3fea055 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 – level-0; the bare metal host, running KVM
+- L0 - level-0; the bare metal host, running KVM
 
-- L1 – level-1 guest; a VM running on L0; also called the "guest
+- L1 - level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 – level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup — L0 (bare
+          resulting in at least four levels in a nested setup - L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter — i.e. to be able to enable
+          with the ``nested`` paramter - i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature — with QEMU, this can be done by using "host passthrough"
+   feature - with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [PATCH 53/53] docs: RCU: avoid using UTF-8 chars
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                   ` (57 preceding siblings ...)
  (?)
@ 2021-05-10 10:27 ` Mauro Carvalho Chehab
  2021-05-11  0:05   ` Paul E. McKenney
  -1 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 10:27 UTC (permalink / raw)
  To: Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Jonathan Corbet,
	Nícolas F. R. A. Prado, Paul E. McKenney, Joel Fernandes,
	Josh Triplett, Lai Jiangshan, Mathieu Desnoyers, Randy Dunlap,
	Sebastian Andrzej Siewior, Steven Rostedt, Takashi Iwai,
	linux-kernel, rcu

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+00a0 (' '): NO-BREAK SPACE
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH
	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../Data-Structures/Data-Structures.rst       |  52 ++++----
 .../Expedited-Grace-Periods.rst               |  40 +++---
 .../Tree-RCU-Memory-Ordering.rst              |  10 +-
 .../RCU/Design/Requirements/Requirements.rst  | 126 +++++++++---------
 4 files changed, 114 insertions(+), 114 deletions(-)

diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
index f4efd6897b09..e95c6c8eeb6a 100644
--- a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
+++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
@@ -301,7 +301,7 @@ The ``->gp_max`` field tracks the duration of the longest grace period
 in jiffies. It is protected by the root ``rcu_node``'s ``->lock``.
 
 The ``->name`` and ``->abbr`` fields distinguish between preemptible RCU
-(“rcu_preempt” and “p”) and non-preemptible RCU (“rcu_sched” and “s”).
+("rcu_preempt" and "p") and non-preemptible RCU ("rcu_sched" and "s").
 These fields are used for diagnostic and tracing purposes.
 
 The ``rcu_node`` Structure
@@ -456,21 +456,21 @@ expedited grace periods, respectively.
 | Lockless grace-period computation! Such a tantalizing possibility!    |
 | But consider the following sequence of events:                        |
 |                                                                       |
-| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
+| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
 |    wakes up, it notices that the current RCU grace period needs it to |
 |    report in, so it sets a flag where the scheduling clock interrupt  |
 |    will find it.                                                      |
-| #. Meanwhile, CPU 1 is running ``force_quiescent_state()``, and       |
-|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |
+| #. Meanwhile, CPU 1 is running ``force_quiescent_state()``, and       |
+|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |
 |    as an extended quiescent state.                                    |
-| #. CPU 0's scheduling clock interrupt fires in the middle of an RCU   |
+| #. CPU 0's scheduling clock interrupt fires in the middle of an RCU   |
 |    read-side critical section, and notices that the RCU core needs    |
 |    something, so commences RCU softirq processing.                    |
-| #. CPU 0's softirq handler executes and is just about ready to report |
+| #. CPU 0's softirq handler executes and is just about ready to report |
 |    its quiescent state up the ``rcu_node`` tree.                      |
-| #. But CPU 1 beats it to the punch, completing the current grace      |
+| #. But CPU 1 beats it to the punch, completing the current grace      |
 |    period and starting a new one.                                     |
-| #. CPU 0 now reports its quiescent state for the wrong grace period.  |
+| #. CPU 0 now reports its quiescent state for the wrong grace period.  |
 |    That grace period might now end before the RCU read-side critical  |
 |    section. If that happens, disaster will ensue.                     |
 |                                                                       |
@@ -515,18 +515,18 @@ removes itself from the ``->blkd_tasks`` list, then that task must
 advance the pointer to the next task on the list, or set the pointer to
 ``NULL`` if there are no subsequent tasks on the list.
 
-For example, suppose that tasks T1, T2, and T3 are all hard-affinitied
-to the largest-numbered CPU in the system. Then if task T1 blocked in an
+For example, suppose that tasks T1, T2, and T3 are all hard-affinitied
+to the largest-numbered CPU in the system. Then if task T1 blocked in an
 RCU read-side critical section, then an expedited grace period started,
-then task T2 blocked in an RCU read-side critical section, then a normal
-grace period started, and finally task 3 blocked in an RCU read-side
+then task T2 blocked in an RCU read-side critical section, then a normal
+grace period started, and finally task 3 blocked in an RCU read-side
 critical section, then the state of the last leaf ``rcu_node``
 structure's blocked-task list would be as shown below:
 
 .. kernel-figure:: blkd_task.svg
 
-Task T1 is blocking both grace periods, task T2 is blocking only the
-normal grace period, and task T3 is blocking neither grace period. Note
+Task T1 is blocking both grace periods, task T2 is blocking only the
+normal grace period, and task T3 is blocking neither grace period. Note
 that these tasks will not remove themselves from this list immediately
 upon resuming execution. They will instead remain on the list until they
 execute the outermost ``rcu_read_unlock()`` that ends their RCU
@@ -611,8 +611,8 @@ expressions as follows:
    66 #endif
 
 The maximum number of levels in the ``rcu_node`` structure is currently
-limited to four, as specified by lines 21-24 and the structure of the
-subsequent “if” statement. For 32-bit systems, this allows
+limited to four, as specified by lines 21-24 and the structure of the
+subsequent "if" statement. For 32-bit systems, this allows
 16*32*32*32=524,288 CPUs, which should be sufficient for the next few
 years at least. For 64-bit systems, 16*64*64*64=4,194,304 CPUs is
 allowed, which should see us through the next decade or so. This
@@ -638,9 +638,9 @@ fields. The number of CPUs per leaf ``rcu_node`` structure is therefore
 limited to 16 given the default value of ``CONFIG_RCU_FANOUT_LEAF``. If
 ``CONFIG_RCU_FANOUT_LEAF`` is unspecified, the value selected is based
 on the word size of the system, just as for ``CONFIG_RCU_FANOUT``.
-Lines 11-19 perform this computation.
+Lines 11-19 perform this computation.
 
-Lines 21-24 compute the maximum number of CPUs supported by a
+Lines 21-24 compute the maximum number of CPUs supported by a
 single-level (which contains a single ``rcu_node`` structure),
 two-level, three-level, and four-level ``rcu_node`` tree, respectively,
 given the fanout specified by ``RCU_FANOUT`` and ``RCU_FANOUT_LEAF``.
@@ -649,18 +649,18 @@ These numbers of CPUs are retained in the ``RCU_FANOUT_1``,
 variables, respectively.
 
 These variables are used to control the C-preprocessor ``#if`` statement
-spanning lines 26-66 that computes the number of ``rcu_node`` structures
+spanning lines 26-66 that computes the number of ``rcu_node`` structures
 required for each level of the tree, as well as the number of levels
 required. The number of levels is placed in the ``NUM_RCU_LVLS``
-C-preprocessor variable by lines 27, 35, 44, and 54. The number of
+C-preprocessor variable by lines 27, 35, 44, and 54. The number of
 ``rcu_node`` structures for the topmost level of the tree is always
 exactly one, and this value is unconditionally placed into
-``NUM_RCU_LVL_0`` by lines 28, 36, 45, and 55. The rest of the levels
+``NUM_RCU_LVL_0`` by lines 28, 36, 45, and 55. The rest of the levels
 (if any) of the ``rcu_node`` tree are computed by dividing the maximum
 number of CPUs by the fanout supported by the number of levels from the
 current level down, rounding up. This computation is performed by
-lines 37, 46-47, and 56-58. Lines 31-33, 40-42, 50-52, and 62-63 create
-initializers for lockdep lock-class names. Finally, lines 64-66 produce
+lines 37, 46-47, and 56-58. Lines 31-33, 40-42, 50-52, and 62-63 create
+initializers for lockdep lock-class names. Finally, lines 64-66 produce
 an error if the maximum number of CPUs is too large for the specified
 fanout.
 
@@ -716,13 +716,13 @@ In this figure, the ``->head`` pointer references the first RCU callback
 in the list. The ``->tails[RCU_DONE_TAIL]`` array element references the
 ``->head`` pointer itself, indicating that none of the callbacks is
 ready to invoke. The ``->tails[RCU_WAIT_TAIL]`` array element references
-callback CB 2's ``->next`` pointer, which indicates that CB 1 and CB 2
+callback CB 2's ``->next`` pointer, which indicates that CB 1 and CB 2
 are both waiting on the current grace period, give or take possible
 disagreements about exactly which grace period is the current one. The
 ``->tails[RCU_NEXT_READY_TAIL]`` array element references the same RCU
 callback that ``->tails[RCU_WAIT_TAIL]`` does, which indicates that
 there are no callbacks waiting on the next RCU grace period. The
-``->tails[RCU_NEXT_TAIL]`` array element references CB 4's ``->next``
+``->tails[RCU_NEXT_TAIL]`` array element references CB 4's ``->next``
 pointer, indicating that all the remaining RCU callbacks have not yet
 been assigned to an RCU grace period. Note that the
 ``->tails[RCU_NEXT_TAIL]`` array element always references the last RCU
@@ -1031,7 +1031,7 @@ field to record the offset of the ``rcu_head`` structure within the
 enclosing RCU-protected data structure.
 
 Both of these fields are used internally by RCU. From the viewpoint of
-RCU users, this structure is an opaque “cookie”.
+RCU users, this structure is an opaque "cookie".
 
 +-----------------------------------------------------------------------+
 | **Quick Quiz**:                                                       |
diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
index 6f89cf1e567d..742921a7532b 100644
--- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
+++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
@@ -304,8 +304,8 @@ representing the elements of the ``->exp_wq[]`` array.
 
 .. kernel-figure:: Funnel0.svg
 
-The next diagram shows the situation after the arrival of Task A and
-Task B at the leftmost and rightmost leaf ``rcu_node`` structures,
+The next diagram shows the situation after the arrival of Task A and
+Task B at the leftmost and rightmost leaf ``rcu_node`` structures,
 respectively. The current value of the ``rcu_state`` structure's
 ``->expedited_sequence`` field is zero, so adding three and clearing the
 bottom bit results in the value two, which both tasks record in the
@@ -313,13 +313,13 @@ bottom bit results in the value two, which both tasks record in the
 
 .. kernel-figure:: Funnel1.svg
 
-Each of Tasks A and B will move up to the root ``rcu_node`` structure.
-Suppose that Task A wins, recording its desired grace-period sequence
+Each of Tasks A and B will move up to the root ``rcu_node`` structure.
+Suppose that Task A wins, recording its desired grace-period sequence
 number and resulting in the state shown below:
 
 .. kernel-figure:: Funnel2.svg
 
-Task A now advances to initiate a new grace period, while Task B moves
+Task A now advances to initiate a new grace period, while Task B moves
 up to the root ``rcu_node`` structure, and, seeing that its desired
 sequence number is already recorded, blocks on ``->exp_wq[1]``.
 
@@ -340,7 +340,7 @@ sequence number is already recorded, blocks on ``->exp_wq[1]``.
 | ``->exp_wq[1]``.                                                      |
 +-----------------------------------------------------------------------+
 
-If Tasks C and D also arrive at this point, they will compute the same
+If Tasks C and D also arrive at this point, they will compute the same
 desired grace-period sequence number, and see that both leaf
 ``rcu_node`` structures already have that value recorded. They will
 therefore block on their respective ``rcu_node`` structures'
@@ -348,52 +348,52 @@ therefore block on their respective ``rcu_node`` structures'
 
 .. kernel-figure:: Funnel3.svg
 
-Task A now acquires the ``rcu_state`` structure's ``->exp_mutex`` and
+Task A now acquires the ``rcu_state`` structure's ``->exp_mutex`` and
 initiates the grace period, which increments ``->expedited_sequence``.
-Therefore, if Tasks E and F arrive, they will compute a desired sequence
+Therefore, if Tasks E and F arrive, they will compute a desired sequence
 number of 4 and will record this value as shown below:
 
 .. kernel-figure:: Funnel4.svg
 
-Tasks E and F will propagate up the ``rcu_node`` combining tree, with
-Task F blocking on the root ``rcu_node`` structure and Task E wait for
-Task A to finish so that it can start the next grace period. The
+Tasks E and F will propagate up the ``rcu_node`` combining tree, with
+Task F blocking on the root ``rcu_node`` structure and Task E wait for
+Task A to finish so that it can start the next grace period. The
 resulting state is as shown below:
 
 .. kernel-figure:: Funnel5.svg
 
-Once the grace period completes, Task A starts waking up the tasks
+Once the grace period completes, Task A starts waking up the tasks
 waiting for this grace period to complete, increments the
 ``->expedited_sequence``, acquires the ``->exp_wake_mutex`` and then
 releases the ``->exp_mutex``. This results in the following state:
 
 .. kernel-figure:: Funnel6.svg
 
-Task E can then acquire ``->exp_mutex`` and increment
-``->expedited_sequence`` to the value three. If new tasks G and H arrive
+Task E can then acquire ``->exp_mutex`` and increment
+``->expedited_sequence`` to the value three. If new tasks G and H arrive
 and moves up the combining tree at the same time, the state will be as
 follows:
 
 .. kernel-figure:: Funnel7.svg
 
 Note that three of the root ``rcu_node`` structure's waitqueues are now
-occupied. However, at some point, Task A will wake up the tasks blocked
+occupied. However, at some point, Task A will wake up the tasks blocked
 on the ``->exp_wq`` waitqueues, resulting in the following state:
 
 .. kernel-figure:: Funnel8.svg
 
-Execution will continue with Tasks E and H completing their grace
+Execution will continue with Tasks E and H completing their grace
 periods and carrying out their wakeups.
 
 +-----------------------------------------------------------------------+
 | **Quick Quiz**:                                                       |
 +-----------------------------------------------------------------------+
-| What happens if Task A takes so long to do its wakeups that Task E's  |
+| What happens if Task A takes so long to do its wakeups that Task E's  |
 | grace period completes?                                               |
 +-----------------------------------------------------------------------+
 | **Answer**:                                                           |
 +-----------------------------------------------------------------------+
-| Then Task E will block on the ``->exp_wake_mutex``, which will also   |
+| Then Task E will block on the ``->exp_wake_mutex``, which will also   |
 | prevent it from releasing ``->exp_mutex``, which in turn will prevent |
 | the next grace period from starting. This last is important in        |
 | preventing overflow of the ``->exp_wq[]`` array.                      |
@@ -464,8 +464,8 @@ code need not worry about POSIX signals. Unfortunately, it has the
 corresponding disadvantage that workqueues cannot be used until they are
 initialized, which does not happen until some time after the scheduler
 spawns the first task. Given that there are parts of the kernel that
-really do want to execute grace periods during this mid-boot “dead
-zone”, expedited grace periods must do something else during thie time.
+really do want to execute grace periods during this mid-boot "dead
+zone", expedited grace periods must do something else during thie time.
 
 What they do is to fall back to the old practice of requiring that the
 requesting task drive the expedited grace period, as was the case before
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index a648b423ba0e..d76c6bfdc659 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37–39. We will therefore abbreviate this
+this discussion are lines 37-39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
@@ -418,7 +418,7 @@ wait on.
 | It is indeed not necessary for the grace period to wait on such a     |
 | critical section. However, it is permissible to wait on it. And it is |
 | furthermore important to wait on it, as this lazy approach is far     |
-| more scalable than a “big bang” all-at-once grace-period start could  |
+| more scalable than a "big bang" all-at-once grace-period start could  |
 | possibly be.                                                          |
 +-----------------------------------------------------------------------+
 
@@ -448,7 +448,7 @@ proceeds upwards from that point, and the ``rcu_node`` ``->lock``
 guarantees that the first CPU's quiescent state happens before the
 remainder of the second CPU's traversal. Applying this line of thought
 repeatedly shows that all CPUs' quiescent states happen before the last
-CPU traverses through the root ``rcu_node`` structure, the “last CPU”
+CPU traverses through the root ``rcu_node`` structure, the "last CPU"
 being the one that clears the last bit in the root ``rcu_node``
 structure's ``->qsmask`` field.
 
@@ -501,8 +501,8 @@ Forcing Quiescent States
 
 As noted above, idle and offline CPUs cannot report their own quiescent
 states, and therefore the grace-period kernel thread must do the
-reporting on their behalf. This process is called “forcing quiescent
-states”, it is repeated every few jiffies, and its ordering effects are
+reporting on their behalf. This process is called "forcing quiescent
+states", it is repeated every few jiffies, and its ordering effects are
 shown below:
 
 .. kernel-figure:: TreeRCU-gp-fqs.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index 38a39476fc24..a3493b34f3dd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -4,7 +4,7 @@ A Tour Through RCU's Requirements
 
 Copyright IBM Corporation, 2015
 
-Author: Paul E. McKenney
+Author: Paul E. McKenney
 
 The initial version of this document appeared in the
 `LWN <https://lwn.net/>`_ on those articles:
@@ -66,7 +66,7 @@ Grace-Period Guarantee
 
 RCU's grace-period guarantee is unusual in being premeditated: Jack
 Slingwine and I had this guarantee firmly in mind when we started work
-on RCU (then called “rclock”) in the early 1990s. That said, the past
+on RCU (then called "rclock") in the early 1990s. That said, the past
 two decades of experience with RCU have produced a much more detailed
 understanding of this guarantee.
 
@@ -102,7 +102,7 @@ overhead to readers, for example:
       15   WRITE_ONCE(y, 1);
       16 }
 
-Because the synchronize_rcu() on line 14 waits for all pre-existing
+Because the synchronize_rcu() on line 14 waits for all pre-existing
 readers, any instance of thread0() that loads a value of zero from
 ``x`` must complete before thread1() stores to ``y``, so that
 instance must also load a value of zero from ``y``. Similarly, any
@@ -178,7 +178,7 @@ little or no synchronization overhead in do_something_dlm().
 +-----------------------------------------------------------------------+
 | **Quick Quiz**:                                                       |
 +-----------------------------------------------------------------------+
-| Why is the synchronize_rcu() on line 28 needed?                       |
+| Why is the synchronize_rcu() on line 28 needed?                       |
 +-----------------------------------------------------------------------+
 | **Answer**:                                                           |
 +-----------------------------------------------------------------------+
@@ -244,7 +244,7 @@ their rights to reorder this code as follows:
       16 }
 
 If an RCU reader fetches ``gp`` just after ``add_gp_buggy_optimized``
-executes line 11, it will see garbage in the ``->a`` and ``->b`` fields.
+executes line 11, it will see garbage in the ``->a`` and ``->b`` fields.
 And this is but one of many ways in which compiler and hardware
 optimizations could cause trouble. Therefore, we clearly need some way
 to prevent the compiler and the CPU from reordering in this manner,
@@ -279,11 +279,11 @@ shows an example of insertion:
       15   return true;
       16 }
 
-The rcu_assign_pointer() on line 13 is conceptually equivalent to a
+The rcu_assign_pointer() on line 13 is conceptually equivalent to a
 simple assignment statement, but also guarantees that its assignment
-will happen after the two assignments in lines 11 and 12, similar to the
+will happen after the two assignments in lines 11 and 12, similar to the
 C11 ``memory_order_release`` store operation. It also prevents any
-number of “interesting” compiler optimizations, for example, the use of
+number of "interesting" compiler optimizations, for example, the use of
 ``gp`` as a scratch location immediately preceding the assignment.
 
 +-----------------------------------------------------------------------+
@@ -410,11 +410,11 @@ This process is implemented by remove_gp_synchronous():
       15   return true;
       16 }
 
-This function is straightforward, with line 13 waiting for a grace
-period before line 14 frees the old data element. This waiting ensures
-that readers will reach line 7 of do_something_gp() before the data
+This function is straightforward, with line 13 waiting for a grace
+period before line 14 frees the old data element. This waiting ensures
+that readers will reach line 7 of do_something_gp() before the data
 element referenced by ``p`` is freed. The rcu_access_pointer() on
-line 6 is similar to rcu_dereference(), except that:
+line 6 is similar to rcu_dereference(), except that:
 
 #. The value returned by rcu_access_pointer() cannot be
    dereferenced. If you want to access the value pointed to as well as
@@ -488,25 +488,25 @@ systems with more than one CPU:
    section ends and the time that synchronize_rcu() returns. Without
    this guarantee, a pre-existing RCU read-side critical section might
    hold a reference to the newly removed ``struct foo`` after the
-   kfree() on line 14 of remove_gp_synchronous().
+   kfree() on line 14 of remove_gp_synchronous().
 #. Each CPU that has an RCU read-side critical section that ends after
    synchronize_rcu() returns is guaranteed to execute a full memory
    barrier between the time that synchronize_rcu() begins and the
    time that the RCU read-side critical section begins. Without this
    guarantee, a later RCU read-side critical section running after the
-   kfree() on line 14 of remove_gp_synchronous() might later run
+   kfree() on line 14 of remove_gp_synchronous() might later run
    do_something_gp() and find the newly deleted ``struct foo``.
 #. If the task invoking synchronize_rcu() remains on a given CPU,
    then that CPU is guaranteed to execute a full memory barrier sometime
    during the execution of synchronize_rcu(). This guarantee ensures
-   that the kfree() on line 14 of remove_gp_synchronous() really
-   does execute after the removal on line 11.
+   that the kfree() on line 14 of remove_gp_synchronous() really
+   does execute after the removal on line 11.
 #. If the task invoking synchronize_rcu() migrates among a group of
    CPUs during that invocation, then each of the CPUs in that group is
    guaranteed to execute a full memory barrier sometime during the
    execution of synchronize_rcu(). This guarantee also ensures that
-   the kfree() on line 14 of remove_gp_synchronous() really does
-   execute after the removal on line 11, but also in the case where the
+   the kfree() on line 14 of remove_gp_synchronous() really does
+   execute after the removal on line 11, but also in the case where the
    thread executing the synchronize_rcu() migrates in the meantime.
 
 +-----------------------------------------------------------------------+
@@ -525,8 +525,8 @@ systems with more than one CPU:
 | In other words, a given instance of synchronize_rcu() can avoid       |
 | waiting on a given RCU read-side critical section only if it can      |
 | prove that synchronize_rcu() started first.                           |
-| A related question is “When rcu_read_lock() doesn't generate any      |
-| code, why does it matter how it relates to a grace period?” The       |
+| A related question is "When rcu_read_lock() doesn't generate any      |
+| code, why does it matter how it relates to a grace period?" The       |
 | answer is that it is not the relationship of rcu_read_lock()          |
 | itself that is important, but rather the relationship of the code     |
 | within the enclosed RCU read-side critical section to the code        |
@@ -538,7 +538,7 @@ systems with more than one CPU:
 | of any access following the grace period.                             |
 |                                                                       |
 | As of late 2016, mathematical models of RCU take this viewpoint, for  |
-| example, see slides 62 and 63 of the `2016 LinuxCon                   |
+| example, see slides 62 and 63 of the `2016 LinuxCon                   |
 | EU <http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.201 |
 | 6.10.04c.LCE.pdf>`__                                                  |
 | presentation.                                                         |
@@ -584,9 +584,9 @@ systems with more than one CPU:
 |                                                                       |
 | And similarly, without a memory barrier between the beginning of the  |
 | grace period and the beginning of the RCU read-side critical section, |
-| CPU 1 might end up accessing the freelist.                            |
+| CPU 1 might end up accessing the freelist.                            |
 |                                                                       |
-| The “as if” rule of course applies, so that any implementation that   |
+| The "as if" rule of course applies, so that any implementation that   |
 | acts as if the appropriate memory barriers were in place is a correct |
 | implementation. That said, it is much easier to fool yourself into    |
 | believing that you have adhered to the as-if rule than it is to       |
@@ -1002,7 +1002,7 @@ RCU implementation must abide by them. They therefore bear repeating:
    ECC errors, NMIs, and other hardware events. Although a delay of more
    than about 20 seconds can result in splats, the RCU implementation is
    obligated to use algorithms that can tolerate extremely long delays,
-   but where “extremely long” is not long enough to allow wrap-around
+   but where "extremely long" is not long enough to allow wrap-around
    when incrementing a 64-bit counter.
 #. Both the compiler and the CPU can reorder memory accesses. Where it
    matters, RCU must use compiler directives and memory-barrier
@@ -1169,7 +1169,7 @@ Energy efficiency is a critical component of performance today, and
 Linux-kernel RCU implementations must therefore avoid unnecessarily
 awakening idle CPUs. I cannot claim that this requirement was
 premeditated. In fact, I learned of it during a telephone conversation
-in which I was given “frank and open” feedback on the importance of
+in which I was given "frank and open" feedback on the importance of
 energy efficiency in battery-powered systems and on specific
 energy-efficiency shortcomings of the Linux-kernel RCU implementation.
 In my experience, the battery-powered embedded community will consider
@@ -1234,7 +1234,7 @@ requirements: A storm of synchronize_rcu_expedited() invocations on
 4096 CPUs should at least make reasonable forward progress. In return
 for its shorter latencies, synchronize_rcu_expedited() is permitted
 to impose modest degradation of real-time latency on non-idle online
-CPUs. Here, “modest” means roughly the same latency degradation as a
+CPUs. Here, "modest" means roughly the same latency degradation as a
 scheduling-clock interrupt.
 
 There are a number of situations where even
@@ -1274,8 +1274,8 @@ be used in place of synchronize_rcu() as follows:
       28 }
 
 A definition of ``struct foo`` is finally needed, and appears on
-lines 1-5. The function remove_gp_cb() is passed to call_rcu()
-on line 25, and will be invoked after the end of a subsequent grace
+lines 1-5. The function remove_gp_cb() is passed to call_rcu()
+on line 25, and will be invoked after the end of a subsequent grace
 period. This gets the same effect as remove_gp_synchronous(), but
 without forcing the updater to wait for a grace period to elapse. The
 call_rcu() function may be used in a number of situations where
@@ -1294,23 +1294,23 @@ threads or (in the Linux kernel) workqueues.
 +-----------------------------------------------------------------------+
 | **Quick Quiz**:                                                       |
 +-----------------------------------------------------------------------+
-| Why does line 19 use rcu_access_pointer()? After all,                 |
-| call_rcu() on line 25 stores into the structure, which would          |
+| Why does line 19 use rcu_access_pointer()? After all,                 |
+| call_rcu() on line 25 stores into the structure, which would          |
 | interact badly with concurrent insertions. Doesn't this mean that     |
 | rcu_dereference() is required?                                        |
 +-----------------------------------------------------------------------+
 | **Answer**:                                                           |
 +-----------------------------------------------------------------------+
-| Presumably the ``->gp_lock`` acquired on line 18 excludes any         |
+| Presumably the ``->gp_lock`` acquired on line 18 excludes any         |
 | changes, including any insertions that rcu_dereference() would        |
 | protect against. Therefore, any insertions will be delayed until      |
-| after ``->gp_lock`` is released on line 25, which in turn means that  |
+| after ``->gp_lock`` is released on line 25, which in turn means that  |
 | rcu_access_pointer() suffices.                                        |
 +-----------------------------------------------------------------------+
 
 However, all that remove_gp_cb() is doing is invoking kfree() on
 the data element. This is a common idiom, and is supported by
-kfree_rcu(), which allows “fire and forget” operation as shown
+kfree_rcu(), which allows "fire and forget" operation as shown
 below:
 
    ::
@@ -1396,8 +1396,8 @@ may be used for this purpose, as shown below:
       18   return true;
       19 }
 
-On line 14, get_state_synchronize_rcu() obtains a “cookie” from RCU,
-then line 15 carries out other tasks, and finally, line 16 returns
+On line 14, get_state_synchronize_rcu() obtains a "cookie" from RCU,
+then line 15 carries out other tasks, and finally, line 16 returns
 immediately if a grace period has elapsed in the meantime, but otherwise
 waits as required. The need for ``get_state_synchronize_rcu`` and
 cond_synchronize_rcu() has appeared quite recently, so it is too
@@ -1420,9 +1420,9 @@ example, an infinite loop in an RCU read-side critical section must by
 definition prevent later grace periods from ever completing. For a more
 involved example, consider a 64-CPU system built with
 ``CONFIG_RCU_NOCB_CPU=y`` and booted with ``rcu_nocbs=1-63``, where
-CPUs 1 through 63 spin in tight loops that invoke call_rcu(). Even
+CPUs 1 through 63 spin in tight loops that invoke call_rcu(). Even
 if these tight loops also contain calls to cond_resched() (thus
-allowing grace periods to complete), CPU 0 simply will not be able to
+allowing grace periods to complete), CPU 0 simply will not be able to
 invoke callbacks as fast as the other 63 CPUs can register them, at
 least not until the system runs out of memory. In both of these
 examples, the Spiderman principle applies: With great power comes great
@@ -1433,7 +1433,7 @@ callbacks.
 RCU takes the following steps to encourage timely completion of grace
 periods:
 
-#. If a grace period fails to complete within 100 milliseconds, RCU
+#. If a grace period fails to complete within 100 milliseconds, RCU
    causes future invocations of cond_resched() on the holdout CPUs
    to provide an RCU quiescent state. RCU also causes those CPUs'
    need_resched() invocations to return ``true``, but only after the
@@ -1442,12 +1442,12 @@ periods:
    indefinitely in the kernel without scheduling-clock interrupts, which
    defeats the above need_resched() strategem. RCU will therefore
    invoke resched_cpu() on any ``nohz_full`` CPUs still holding out
-   after 109 milliseconds.
+   after 109 milliseconds.
 #. In kernels built with ``CONFIG_RCU_BOOST=y``, if a given task that
    has been preempted within an RCU read-side critical section is
-   holding out for more than 500 milliseconds, RCU will resort to
+   holding out for more than 500 milliseconds, RCU will resort to
    priority boosting.
-#. If a CPU is still holding out 10 seconds into the grace period, RCU
+#. If a CPU is still holding out 10 seconds into the grace period, RCU
    will invoke resched_cpu() on it regardless of its ``nohz_full``
    state.
 
@@ -1579,7 +1579,7 @@ period.
 Software-Engineering Requirements
 ---------------------------------
 
-Between Murphy's Law and “To err is human”, it is necessary to guard
+Between Murphy's Law and "To err is human", it is necessary to guard
 against mishaps and misuse:
 
 #. It is all too easy to forget to use rcu_read_lock() everywhere
@@ -1626,7 +1626,7 @@ against mishaps and misuse:
    `patch <https://lore.kernel.org/r/20100319013024.GA28456@Krystal>`__.
 #. An infinite loop in an RCU read-side critical section will eventually
    trigger an RCU CPU stall warning splat, with the duration of
-   “eventually” being controlled by the ``RCU_CPU_STALL_TIMEOUT``
+   "eventually" being controlled by the ``RCU_CPU_STALL_TIMEOUT``
    ``Kconfig`` option, or, alternatively, by the
    ``rcupdate.rcu_cpu_stall_timeout`` boot/sysfs parameter. However, RCU
    is not obligated to produce this splat unless there is a grace period
@@ -1704,7 +1704,7 @@ Configuration
 
 RCU's goal is automatic configuration, so that almost nobody needs to
 worry about RCU's ``Kconfig`` options. And for almost all users, RCU
-does in fact work well “out of the box.”
+does in fact work well "out of the box."
 
 However, there are specialized use cases that are handled by kernel boot
 parameters and ``Kconfig`` options. Unfortunately, the ``Kconfig``
@@ -1733,7 +1733,7 @@ listings.
 
 RCU must therefore wait for a given CPU to actually come online before
 it can allow itself to believe that the CPU actually exists. The
-resulting “ghost CPUs” (which are never going to come online) cause a
+resulting "ghost CPUs" (which are never going to come online) cause a
 number of `interesting
 complications <https://paulmck.livejournal.com/37494.html>`__.
 
@@ -1789,7 +1789,7 @@ normally.
 | **Answer**:                                                           |
 +-----------------------------------------------------------------------+
 | Very carefully!                                                       |
-| During the “dead zone” between the time that the scheduler spawns the |
+| During the "dead zone" between the time that the scheduler spawns the |
 | first task and the time that all of RCU's kthreads have been spawned, |
 | all synchronous grace periods are handled by the expedited            |
 | grace-period mechanism. At runtime, this expedited mechanism relies   |
@@ -1824,7 +1824,7 @@ Some Linux-kernel architectures can enter an interrupt handler from
 non-idle process context, and then just never leave it, instead
 stealthily transitioning back to process context. This trick is
 sometimes used to invoke system calls from inside the kernel. These
-“half-interrupts” mean that RCU has to be very careful about how it
+"half-interrupts" mean that RCU has to be very careful about how it
 counts interrupt nesting levels. I learned of this requirement the hard
 way during a rewrite of RCU's dyntick-idle code.
 
@@ -1921,7 +1921,7 @@ and go. It is of course illegal to use any RCU API member from an
 offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side
 critical sections. This requirement was present from day one in
 DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug
-implementation is “interesting.”
+implementation is "interesting."
 
 The Linux-kernel CPU-hotplug implementation has notifiers that are used
 to allow the various kernel subsystems (including RCU) to respond
@@ -2268,7 +2268,7 @@ remain zero during all phases of grace-period processing, and that bit
 happens to map to the bottom bit of the ``rcu_head`` structure's
 ``->next`` field. RCU makes this guarantee as long as call_rcu() is
 used to post the callback, as opposed to kfree_rcu() or some future
-“lazy” variant of call_rcu() that might one day be created for
+"lazy" variant of call_rcu() that might one day be created for
 energy-efficiency purposes.
 
 That said, there are limits. RCU requires that the ``rcu_head``
@@ -2281,7 +2281,7 @@ architecture provides only two-byte alignment, and thus acts as
 alignment's least common denominator.
 
 The reason for reserving the bottom bit of pointers to ``rcu_head``
-structures is to leave the door open to “lazy” callbacks whose
+structures is to leave the door open to "lazy" callbacks whose
 invocations can safely be deferred. Deferring invocation could
 potentially have energy-efficiency benefits, but only if the rate of
 non-lazy callbacks decreases significantly for some important workload.
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting—and perhaps
-unprecedented—validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting-and perhaps
+unprecedented-validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
@@ -2399,7 +2399,7 @@ single flavor. The read-side API remains, and continues to disable
 softirq and to be accounted for by lockdep. Much of the material in this
 section is therefore strictly historical in nature.
 
-The softirq-disable (AKA “bottom-half”, hence the “_bh” abbreviations)
+The softirq-disable (AKA "bottom-half", hence the "_bh" abbreviations)
 flavor of RCU, or *RCU-bh*, was developed by Dipankar Sarma to provide a
 flavor of RCU that could withstand the network-based denial-of-service
 attacks researched by Robert Olsson. These attacks placed so much
@@ -2458,7 +2458,7 @@ effect of also waiting for all pre-existing interrupt and NMI handlers.
 However, there are legitimate preemptible-RCU implementations that do
 not have this property, given that any point in the code outside of an
 RCU read-side critical section can be a quiescent state. Therefore,
-*RCU-sched* was created, which follows “classic” RCU in that an
+*RCU-sched* was created, which follows "classic" RCU in that an
 RCU-sched grace period waits for pre-existing interrupt and NMI
 handlers. In kernels built with ``CONFIG_PREEMPTION=n``, the RCU and
 RCU-sched APIs have identical implementations, while kernels built with
@@ -2490,8 +2490,8 @@ and local_irq_restore(), and so on.
 Sleepable RCU
 ~~~~~~~~~~~~~
 
-For well over a decade, someone saying “I need to block within an RCU
-read-side critical section” was a reliable indication that this someone
+For well over a decade, someone saying "I need to block within an RCU
+read-side critical section" was a reliable indication that this someone
 did not understand RCU. After all, if you are always blocking in an RCU
 read-side critical section, you can probably afford to use a
 higher-overhead synchronization mechanism. However, that changed with
@@ -2507,7 +2507,7 @@ this structure must be passed in to each SRCU function, for example,
 structure. The key benefit of these domains is that a slow SRCU reader
 in one domain does not delay an SRCU grace period in some other domain.
 That said, one consequence of these domains is that read-side code must
-pass a “cookie” from srcu_read_lock() to srcu_read_unlock(), for
+pass a "cookie" from srcu_read_lock() to srcu_read_unlock(), for
 example, as follows:
 
    ::
@@ -2536,9 +2536,9 @@ period to elapse. For example, this results in a self-deadlock:
        5 synchronize_srcu(&ss);
        6 srcu_read_unlock(&ss, idx);
 
-However, if line 5 acquired a mutex that was held across a
+However, if line 5 acquired a mutex that was held across a
 synchronize_srcu() for domain ``ss``, deadlock would still be
-possible. Furthermore, if line 5 acquired a mutex that was held across a
+possible. Furthermore, if line 5 acquired a mutex that was held across a
 synchronize_srcu() for some other domain ``ss1``, and if an
 ``ss1``-domain SRCU read-side critical section acquired another mutex
 that was held across as ``ss``-domain synchronize_srcu(), deadlock
@@ -2557,7 +2557,7 @@ memory barrier.
 Also unlike other RCU flavors, synchronize_srcu() may **not** be
 invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
 periods make use of timers and the possibility of timers being
-temporarily “stranded” on the outgoing CPU. This stranding of timers
+temporarily "stranded" on the outgoing CPU. This stranding of timers
 means that timers posted to the outgoing CPU will not fire until late in
 the CPU-hotplug process. The problem is that if a notifier is waiting on
 an SRCU grace period, that grace period is waiting on a timer, and that
@@ -2573,7 +2573,7 @@ period has the side effect of expediting all prior grace periods that
 have not yet completed. (But please note that this is a property of the
 current implementation, not necessarily of future implementations.) In
 addition, if SRCU has been idle for longer than the interval specified
-by the ``srcutree.exp_holdoff`` kernel boot parameter (25 microseconds
+by the ``srcutree.exp_holdoff`` kernel boot parameter (25 microseconds
 by default), and if a synchronize_srcu() invocation ends this idle
 period, that invocation will be automatically expedited.
 
@@ -2619,7 +2619,7 @@ from the cache, an SRCU grace period will be very likely to have elapsed.
 Tasks RCU
 ~~~~~~~~~
 
-Some forms of tracing use “trampolines” to handle the binary rewriting
+Some forms of tracing use "trampolines" to handle the binary rewriting
 required to install different types of probes. It would be good to be
 able to free old trampolines, which sounds like a job for some form of
 RCU. However, because it is necessary to be able to install a trace
@@ -2687,7 +2687,7 @@ your architecture should also benefit from the
 number of CPUs in a socket, NUMA node, or whatever. If the number of
 CPUs is too large, use a fraction of the number of CPUs. If the number
 of CPUs is a large prime number, well, that certainly is an
-“interesting” architectural choice! More flexible arrangements might be
+"interesting" architectural choice! More flexible arrangements might be
 considered, but only if ``rcutree.rcu_fanout_leaf`` has proven
 inadequate, and only if the inadequacy has been demonstrated by a
 carefully run and realistic system-level workload.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [PATCH 43/53] docs: PCI: acpi-info.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 43/53] docs: PCI: acpi-info.rst: " Mauro Carvalho Chehab
@ 2021-05-10 10:37   ` Krzysztof Wilczyński
  0 siblings, 0 replies; 219+ messages in thread
From: Krzysztof Wilczyński @ 2021-05-10 10:37 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Bjorn Helgaas,
	linux-kernel, linux-pci

Hi Mauro,

> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+00a0 (' '): NO-BREAK SPACE
> 	- U+2013 ('–'): EN DASH
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
[...]

Thank you!

Reviewed-by: Krzysztof Wilczyński <kw@linux.com>

Krzysztof

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 39/53] docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 39/53] docs: dev-tools: testing-overview.rst: " Mauro Carvalho Chehab
@ 2021-05-10 10:48   ` Marco Elver
  2021-05-12  8:52     ` Mauro Carvalho Chehab
  2021-05-10 23:35   ` David Gow
  1 sibling, 1 reply; 219+ messages in thread
From: Marco Elver @ 2021-05-10 10:48 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Daniel Latypov, David Gow, LKML

On Mon, 10 May 2021 at 12:27, Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
>         - U+2014 ('—'): EM DASH
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/dev-tools/testing-overview.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
> index b5b46709969c..8adffc26a2ec 100644
> --- a/Documentation/dev-tools/testing-overview.rst
> +++ b/Documentation/dev-tools/testing-overview.rst
> @@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
>  groups of tests easier, as well as providing helpers to aid in writing new
>  tests.
>
> -If you're looking to verify the behaviour of the Kernel — particularly specific
> -parts of the kernel — then you'll want to use KUnit or kselftest.
> +If you're looking to verify the behaviour of the Kernel - particularly specific
> +parts of the kernel - then you'll want to use KUnit or kselftest.

Single dash is incorrect punctuation here. So that Sphinx gives us the
correct em dash, these should be '--'.

Thanks,
-- Marco

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                     ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  -1 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> […]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> […]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  0 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> […]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> […]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  0 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, linux-rdma, x86,
	linux-acpi, intel-wired-lan, linux-input, linux-ext4, intel-gfx,
	linux-media, linux-pm, linux-sgx, coresight, rcu, mjpeg-users,
	linux-arm-kernel, linux-edac, linux-hwmon, netdev, linux-usb,
	linux-kernel, linux-f2fs-devel, linux-integrity


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> […]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> […]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  0 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, linux-rdma, x86,
	linux-acpi, intel-wired-lan, linux-input, linux-ext4, intel-gfx,
	linux-media, linux-pm, linux-sgx, coresight, rcu, mjpeg-users,
	linux-arm-kernel, linux-edac, linux-hwmon, netdev, linux-usb,
	linux-kernel, linux-f2fs-devel, linux-integrity


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> […]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> […]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  0 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> […]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> […]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  0 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, linux-rdma, x86,
	linux-acpi, intel-wired-lan, linux-input, linux-ext4, intel-gfx,
	linux-media, linux-pm, linux-sgx, coresight, rcu, mjpeg-users,
	linux-arm-kernel, linux-edac, linux-hwmon, netdev, linux-usb,
	linux-kernel, linux-f2fs-devel, linux-integrity


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> […]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> […]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:52   ` Thorsten Leemhuis
  0 siblings, 0 replies; 219+ messages in thread
From: Thorsten Leemhuis @ 2021-05-10 10:52 UTC (permalink / raw)
  To: intel-wired-lan


On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
>
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.
> [?]
> The remaining patches on series address such cases on *.rst files and 
> inside the Documentation/ABI, using this perl map table in order to do the
> charset conversion:
> 
> my %char_map = (
> [?]
> 	0x2013 => '-',		# EN DASH
> 	0x2014 => '-',		# EM DASH

I might be performing bike shedding here, but wouldn't it be better to
replace those two with "--", as explained in
https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens

For EM DASH there seems to be even "---", but I'd say that is a bit too
much.

Or do you fear the extra work as some lines then might break the
80-character limit then?

Ciao, Thorsten

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                     ` (3 preceding siblings ...)
  (?)
@ 2021-05-10 10:54   ` David Woodhouse
  -1 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 10:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
> 
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used on that time.
> 
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.

No, that is absolutely the wrong approach.

If someone has a local setup which makes bogus assumptions about text
encodings, that is their own mistake.

We don't do them any favours by trying to *hide* it in the common case
so that they don't notice it for longer.

There really isn't much excuse for such brokenness, this far into the
21st century.

Even *before* UTF-8 came along in the final decade of the last
millennium, it was important to know which character set a given piece
of text was encoded in.

In fact it was even *more* important back then, we couldn't just assume
UTF-8 everywhere like we can in modern times.

Git can already do things like CRLF conversion on checking files out to
match local conventions; if you want to teach it to do character set
conversions too then I suppose that might be useful to a few developers
who've fallen through a time warp and still need it. But nobody's ever
bothered before because it just isn't necessary these days.

Please *don't* attempt to address this anachronistic and esoteric
"requirement" by dragging the kernel source back in time by three
decades.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:54   ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 10:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


[-- Attachment #1.1: Type: text/plain, Size: 1749 bytes --]

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
> 
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used on that time.
> 
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.

No, that is absolutely the wrong approach.

If someone has a local setup which makes bogus assumptions about text
encodings, that is their own mistake.

We don't do them any favours by trying to *hide* it in the common case
so that they don't notice it for longer.

There really isn't much excuse for such brokenness, this far into the
21st century.

Even *before* UTF-8 came along in the final decade of the last
millennium, it was important to know which character set a given piece
of text was encoded in.

In fact it was even *more* important back then, we couldn't just assume
UTF-8 everywhere like we can in modern times.

Git can already do things like CRLF conversion on checking files out to
match local conventions; if you want to teach it to do character set
conversions too then I suppose that might be useful to a few developers
who've fallen through a time warp and still need it. But nobody's ever
bothered before because it just isn't necessary these days.

Please *don't* attempt to address this anachronistic and esoteric
"requirement" by dragging the kernel source back in time by three
decades.



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:54   ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 10:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, linux-rdma, x86,
	linux-acpi, intel-wired-lan, linux-input, linux-ext4, intel-gfx,
	linux-media, linux-pm, linux-sgx, coresight, rcu, mjpeg-users,
	linux-arm-kernel, linux-edac, linux-hwmon, netdev, linux-usb,
	linux-kernel, linux-f2fs-devel, linux-integrity

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
> 
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used on that time.
> 
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.

No, that is absolutely the wrong approach.

If someone has a local setup which makes bogus assumptions about text
encodings, that is their own mistake.

We don't do them any favours by trying to *hide* it in the common case
so that they don't notice it for longer.

There really isn't much excuse for such brokenness, this far into the
21st century.

Even *before* UTF-8 came along in the final decade of the last
millennium, it was important to know which character set a given piece
of text was encoded in.

In fact it was even *more* important back then, we couldn't just assume
UTF-8 everywhere like we can in modern times.

Git can already do things like CRLF conversion on checking files out to
match local conventions; if you want to teach it to do character set
conversions too then I suppose that might be useful to a few developers
who've fallen through a time warp and still need it. But nobody's ever
bothered before because it just isn't necessary these days.

Please *don't* attempt to address this anachronistic and esoteric
"requirement" by dragging the kernel source back in time by three
decades.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:54   ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 10:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


[-- Attachment #1.1: Type: text/plain, Size: 1749 bytes --]

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
> 
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used on that time.
> 
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.

No, that is absolutely the wrong approach.

If someone has a local setup which makes bogus assumptions about text
encodings, that is their own mistake.

We don't do them any favours by trying to *hide* it in the common case
so that they don't notice it for longer.

There really isn't much excuse for such brokenness, this far into the
21st century.

Even *before* UTF-8 came along in the final decade of the last
millennium, it was important to know which character set a given piece
of text was encoded in.

In fact it was even *more* important back then, we couldn't just assume
UTF-8 everywhere like we can in modern times.

Git can already do things like CRLF conversion on checking files out to
match local conventions; if you want to teach it to do character set
conversions too then I suppose that might be useful to a few developers
who've fallen through a time warp and still need it. But nobody's ever
bothered before because it just isn't necessary these days.

Please *don't* attempt to address this anachronistic and esoteric
"requirement" by dragging the kernel source back in time by three
decades.



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:54   ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 10:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: alsa-devel, kvm, linux-iio, linux-pci, linux-fpga, dri-devel,
	keyrings, linux-riscv, Jonathan Corbet, linux-rdma, x86,
	linux-acpi, intel-wired-lan, linux-input, linux-ext4, intel-gfx,
	linux-media, linux-pm, linux-sgx, coresight, rcu, mjpeg-users,
	linux-arm-kernel, linux-edac, linux-hwmon, netdev, linux-usb,
	linux-kernel, linux-f2fs-devel, linux-integrity


[-- Attachment #1.1: Type: text/plain, Size: 1749 bytes --]

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
> 
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used on that time.
> 
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.

No, that is absolutely the wrong approach.

If someone has a local setup which makes bogus assumptions about text
encodings, that is their own mistake.

We don't do them any favours by trying to *hide* it in the common case
so that they don't notice it for longer.

There really isn't much excuse for such brokenness, this far into the
21st century.

Even *before* UTF-8 came along in the final decade of the last
millennium, it was important to know which character set a given piece
of text was encoded in.

In fact it was even *more* important back then, we couldn't just assume
UTF-8 everywhere like we can in modern times.

Git can already do things like CRLF conversion on checking files out to
match local conventions; if you want to teach it to do character set
conversions too then I suppose that might be useful to a few developers
who've fallen through a time warp and still need it. But nobody's ever
bothered before because it just isn't necessary these days.

Please *don't* attempt to address this anachronistic and esoteric
"requirement" by dragging the kernel source back in time by three
decades.



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 10:54   ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 10:54 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
> 
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used on that time.
> 
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset, better to use UTF-8 only on cases where it is really
> needed.

No, that is absolutely the wrong approach.

If someone has a local setup which makes bogus assumptions about text
encodings, that is their own mistake.

We don't do them any favours by trying to *hide* it in the common case
so that they don't notice it for longer.

There really isn't much excuse for such brokenness, this far into the
21st century.

Even *before* UTF-8 came along in the final decade of the last
millennium, it was important to know which character set a given piece
of text was encoded in.

In fact it was even *more* important back then, we couldn't just assume
UTF-8 everywhere like we can in modern times.

Git can already do things like CRLF conversion on checking files out to
match local conventions; if you want to teach it to do character set
conversions too then I suppose that might be useful to a few developers
who've fallen through a time warp and still need it. But nobody's ever
bothered before because it just isn't necessary these days.

Please *don't* attempt to address this anachronistic and esoteric
"requirement" by dragging the kernel source back in time by three
decades.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210510/66ecbb60/attachment-0001.bin>

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
  2021-05-10 10:26   ` Mauro Carvalho Chehab
  (?)
@ 2021-05-10 11:16     ` Jani Nikula
  -1 siblings, 0 replies; 219+ messages in thread
From: Jani Nikula @ 2021-05-10 11:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: Mauro Carvalho Chehab, Mali DP Maintainers, James (Qian) Wang,
	Jonathan Corbet, Daniel Vetter, David Airlie, Joonas Lahtinen,
	Liviu Dudau, Maarten Lankhorst, Maxime Ripard, Mihail Atanassov,
	Rodrigo Vivi, Thomas Zimmermann, dri-devel, intel-gfx,
	linux-kernel

On Mon, 10 May 2021, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Acked-by: Jani Nikula <jani.nikula@intel.com>


> ---
>  Documentation/gpu/i915.rst       | 2 +-
>  Documentation/gpu/komeda-kms.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 486c720f3890..2cbf54460b48 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -361,7 +361,7 @@ Locking Guidelines
>  	  real bad.
>  
>  #. Do not nest different lru/memory manager locks within each other.
> -   Take them in turn to update memory allocations, relying on the object’s
> +   Take them in turn to update memory allocations, relying on the object's
>     dma_resv ww_mutex to serialize against other operations.
>  
>  #. The suggestion for lru/memory managers locks is that they are small
> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
> index eb693c857e2d..c2067678e92c 100644
> --- a/Documentation/gpu/komeda-kms.rst
> +++ b/Documentation/gpu/komeda-kms.rst
> @@ -324,7 +324,7 @@ the control-abilites of device.
>  
>  We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
>  pipelines. Since komeda is not for D71 only but also intended for later products,
> -of course we’d better share as much as possible between different products. To
> +of course we'd better share as much as possible between different products. To
>  achieve this, split the komeda device into two layers: CORE and CHIP.
>  
>  -   CORE: for common features and capabilities handling.

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
@ 2021-05-10 11:16     ` Jani Nikula
  0 siblings, 0 replies; 219+ messages in thread
From: Jani Nikula @ 2021-05-10 11:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: Thomas Zimmermann, Jonathan Corbet, Mauro Carvalho Chehab,
	intel-gfx, Liviu Dudau, linux-kernel, David Airlie,
	James (Qian) Wang, dri-devel, Rodrigo Vivi, Mali DP Maintainers,
	Mihail Atanassov

On Mon, 10 May 2021, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Acked-by: Jani Nikula <jani.nikula@intel.com>


> ---
>  Documentation/gpu/i915.rst       | 2 +-
>  Documentation/gpu/komeda-kms.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 486c720f3890..2cbf54460b48 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -361,7 +361,7 @@ Locking Guidelines
>  	  real bad.
>  
>  #. Do not nest different lru/memory manager locks within each other.
> -   Take them in turn to update memory allocations, relying on the object’s
> +   Take them in turn to update memory allocations, relying on the object's
>     dma_resv ww_mutex to serialize against other operations.
>  
>  #. The suggestion for lru/memory managers locks is that they are small
> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
> index eb693c857e2d..c2067678e92c 100644
> --- a/Documentation/gpu/komeda-kms.rst
> +++ b/Documentation/gpu/komeda-kms.rst
> @@ -324,7 +324,7 @@ the control-abilites of device.
>  
>  We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
>  pipelines. Since komeda is not for D71 only but also intended for later products,
> -of course we’d better share as much as possible between different products. To
> +of course we'd better share as much as possible between different products. To
>  achieve this, split the komeda device into two layers: CORE and CHIP.
>  
>  -   CORE: for common features and capabilities handling.

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
@ 2021-05-10 11:16     ` Jani Nikula
  0 siblings, 0 replies; 219+ messages in thread
From: Jani Nikula @ 2021-05-10 11:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: Thomas Zimmermann, Jonathan Corbet, Mauro Carvalho Chehab,
	intel-gfx, linux-kernel, Maxime Ripard, David Airlie,
	James (Qian) Wang, dri-devel, Mali DP Maintainers,
	Mihail Atanassov

On Mon, 10 May 2021, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Acked-by: Jani Nikula <jani.nikula@intel.com>


> ---
>  Documentation/gpu/i915.rst       | 2 +-
>  Documentation/gpu/komeda-kms.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 486c720f3890..2cbf54460b48 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -361,7 +361,7 @@ Locking Guidelines
>  	  real bad.
>  
>  #. Do not nest different lru/memory manager locks within each other.
> -   Take them in turn to update memory allocations, relying on the object’s
> +   Take them in turn to update memory allocations, relying on the object's
>     dma_resv ww_mutex to serialize against other operations.
>  
>  #. The suggestion for lru/memory managers locks is that they are small
> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
> index eb693c857e2d..c2067678e92c 100644
> --- a/Documentation/gpu/komeda-kms.rst
> +++ b/Documentation/gpu/komeda-kms.rst
> @@ -324,7 +324,7 @@ the control-abilites of device.
>  
>  We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
>  pipelines. Since komeda is not for D71 only but also intended for later products,
> -of course we’d better share as much as possible between different products. To
> +of course we'd better share as much as possible between different products. To
>  achieve this, split the komeda device into two layers: CORE and CHIP.
>  
>  -   CORE: for common features and capabilities handling.

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 10:52   ` Thorsten Leemhuis
                       ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > […]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > […]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > […]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > […]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > […]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > […]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > […]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > […]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > […]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > […]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > […]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > […]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:19     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:19 UTC (permalink / raw)
  To: intel-wired-lan

Em Mon, 10 May 2021 12:52:44 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> On 10.05.21 12:26, Mauro Carvalho Chehab wrote:
> >
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.
> > [?]
> > The remaining patches on series address such cases on *.rst files and 
> > inside the Documentation/ABI, using this perl map table in order to do the
> > charset conversion:
> > 
> > my %char_map = (
> > [?]
> > 	0x2013 => '-',		# EN DASH
> > 	0x2014 => '-',		# EM DASH  


> I might be performing bike shedding here, but wouldn't it be better to
> replace those two with "--", as explained in
> https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> 
> For EM DASH there seems to be even "---", but I'd say that is a bit too
> much.

Yeah, we can do, instead:

 	0x2013 => '--',		# EN DASH
 	0x2014 => '---',	# EM DASH  

I was actually in doubt about those ;-)

Btw, when producing HTML documentation,  Sphinx should convert:
	-- into EN DASH
and:
	--- into EM DASH

So, the resulting html will be identical.

> Or do you fear the extra work as some lines then might break the
> 80-character limit then?

No, I suspect that the line size won't be an issue. Some care should
taken when EN DASH and EM DASH are used inside tables.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 10:54   ` David Woodhouse
                       ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('‐'): HYPHEN
	- U+00ad ('­'): SOFT HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('´'): ACUTE ACCENT

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2212 ('−'): MINUS SIGN

	- U+2217 ('∗'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 (' '): NO-BREAK SPACE
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('‐'): HYPHEN
	- U+00ad ('­'): SOFT HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('´'): ACUTE ACCENT

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2212 ('−'): MINUS SIGN

	- U+2217 ('∗'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 (' '): NO-BREAK SPACE
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('‐'): HYPHEN
	- U+00ad ('­'): SOFT HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('´'): ACUTE ACCENT

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2212 ('−'): MINUS SIGN

	- U+2217 ('∗'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 (' '): NO-BREAK SPACE
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('‐'): HYPHEN
	- U+00ad ('­'): SOFT HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('´'): ACUTE ACCENT

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2212 ('−'): MINUS SIGN

	- U+2217 ('∗'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 (' '): NO-BREAK SPACE
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('‐'): HYPHEN
	- U+00ad ('­'): SOFT HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('´'): ACUTE ACCENT

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2212 ('−'): MINUS SIGN

	- U+2217 ('∗'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 (' '): NO-BREAK SPACE
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('‐'): HYPHEN
	- U+00ad ('­'): SOFT HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2014 ('—'): EM DASH

	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('´'): ACUTE ACCENT

	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('×'): MULTIPLICATION SIGN
	- U+2212 ('−'): MINUS SIGN

	- U+2217 ('∗'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 (' '): NO-BREAK SPACE
	- U+feff (''): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 11:55     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 11:55 UTC (permalink / raw)
  To: intel-wired-lan

Hi David,

Em Mon, 10 May 2021 11:54:02 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> > There are several UTF-8 characters at the Kernel's documentation.
> > 
> > Several of them were due to the process of converting files from
> > DocBook, LaTeX, HTML and Markdown. They were probably introduced
> > by the conversion tools used on that time.
> > 
> > Other UTF-8 characters were added along the time, but they're easily
> > replaceable by ASCII chars.
> > 
> > As Linux developers are all around the globe, and not everybody has UTF-8
> > as their default charset, better to use UTF-8 only on cases where it is really
> > needed.  
> 
> No, that is absolutely the wrong approach.
> 
> If someone has a local setup which makes bogus assumptions about text
> encodings, that is their own mistake.
> 
> We don't do them any favours by trying to *hide* it in the common case
> so that they don't notice it for longer.
> 
> There really isn't much excuse for such brokenness, this far into the
> 21st century.
> 
> Even *before* UTF-8 came along in the final decade of the last
> millennium, it was important to know which character set a given piece
> of text was encoded in.
> 
> In fact it was even *more* important back then, we couldn't just assume
> UTF-8 everywhere like we can in modern times.
> 
> Git can already do things like CRLF conversion on checking files out to
> match local conventions; if you want to teach it to do character set
> conversions too then I suppose that might be useful to a few developers
> who've fallen through a time warp and still need it. But nobody's ever
> bothered before because it just isn't necessary these days.
> 
> Please *don't* attempt to address this anachronistic and esoteric
> "requirement" by dragging the kernel source back in time by three
> decades.

No. The idea is not to go back three decades ago. 

The goal is just to avoid use UTF-8 where it is not needed. See, the vast
majority of UTF-8 chars are kept:

	- Non-ASCII Latin and Greek chars;
	- Box drawings;
	- arrows;
	- most symbols.

There, it makes perfect sense to keep using UTF-8.

We should keep using UTF-8 on Kernel. This is something that it shouldn't
be changed.

---

This patch series is doing conversion only when using ASCII makes
more sense than using UTF-8. 

See, a number of converted documents ended with weird characters
like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
character doesn't do any good.

Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
someone tries to use grep[1].

[1] try to run:

    $ git grep "CPU 0 has been" Documentation/RCU/

    it will return nothing with current upstream.

    But it will work fine after the series is applied:

    $ git grep "CPU 0 has been" Documentation/RCU/
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
      Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The main point on this series is to replace just the occurrences
where ASCII represents the symbol equally well, e. g. it is limited
for those chars:

	- U+2010 ('?'): HYPHEN
	- U+00ad ('?'): SOFT HYPHEN
	- U+2013 ('?'): EN DASH
	- U+2014 ('?'): EM DASH

	- U+2018 ('?'): LEFT SINGLE QUOTATION MARK
	- U+2019 ('?'): RIGHT SINGLE QUOTATION MARK
	- U+00b4 ('?'): ACUTE ACCENT

	- U+201c ('?'): LEFT DOUBLE QUOTATION MARK
	- U+201d ('?'): RIGHT DOUBLE QUOTATION MARK

	- U+00d7 ('?'): MULTIPLICATION SIGN
	- U+2212 ('?'): MINUS SIGN

	- U+2217 ('?'): ASTERISK OPERATOR
	  (this one used as a pointer reference like "*foo" on C code
	   example inside a document converted from LaTeX)

	- U+00bb ('?'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
	  (this one also used wrongly on an ABI file, meaning '>')

	- U+00a0 ('?'): NO-BREAK SPACE
	- U+feff ('?'): ZERO WIDTH NO-BREAK SPACE

Using the above symbols will just trick tools like grep for no good
reason.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 11:19     ` Mauro Carvalho Chehab
                         ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > […]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > […]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40°C to +125°C.
	+operation over a temperature range of --40°C to +125°C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of -40°C to +125°C.
+operation over a temperature range of --40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (-10°C to +100°C)
+Accuracy: ±1°C Typ (--10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > […]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > […]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40°C to +125°C.
	+operation over a temperature range of --40°C to +125°C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of -40°C to +125°C.
+operation over a temperature range of --40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (-10°C to +100°C)
+Accuracy: ±1°C Typ (--10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > […]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > […]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40°C to +125°C.
	+operation over a temperature range of --40°C to +125°C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of -40°C to +125°C.
+operation over a temperature range of --40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (-10°C to +100°C)
+Accuracy: ±1°C Typ (--10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > […]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > […]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40°C to +125°C.
	+operation over a temperature range of --40°C to +125°C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of -40°C to +125°C.
+operation over a temperature range of --40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (-10°C to +100°C)
+Accuracy: ±1°C Typ (--10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::


^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > […]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > […]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40°C to +125°C.
	+operation over a temperature range of --40°C to +125°C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of -40°C to +125°C.
+operation over a temperature range of --40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (-10°C to +100°C)
+Accuracy: ±1°C Typ (--10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: Thorsten Leemhuis
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > […]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > […]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40°C to +125°C.
	+operation over a temperature range of --40°C to +125°C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bjørn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1°C. The TMP103 is specified for
-operation over a temperature range of -40°C to +125°C.
+operation over a temperature range of --40°C to +125°C.
 
 Resolution: 8 Bits
-Accuracy: ±1°C Typ (-10°C to +100°C)
+Accuracy: ±1°C Typ (--10°C to +100°C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 12:27       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 12:27 UTC (permalink / raw)
  To: intel-wired-lan

Em Mon, 10 May 2021 13:19:50 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Mon, 10 May 2021 12:52:44 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > On 10.05.21 12:26, Mauro Carvalho Chehab wrote:  
> > >
> > > As Linux developers are all around the globe, and not everybody has UTF-8
> > > as their default charset, better to use UTF-8 only on cases where it is really
> > > needed.
> > > [?]
> > > The remaining patches on series address such cases on *.rst files and 
> > > inside the Documentation/ABI, using this perl map table in order to do the
> > > charset conversion:
> > > 
> > > my %char_map = (
> > > [?]
> > > 	0x2013 => '-',		# EN DASH
> > > 	0x2014 => '-',		# EM DASH    
> 
> 
> > I might be performing bike shedding here, but wouldn't it be better to
> > replace those two with "--", as explained in
> > https://en.wikipedia.org/wiki/Dash#Approximating_the_em_dash_with_two_or_three_hyphens
> > 
> > For EM DASH there seems to be even "---", but I'd say that is a bit too
> > much.  
> 
> Yeah, we can do, instead:
> 
>  	0x2013 => '--',		# EN DASH
>  	0x2014 => '---',	# EM DASH  
> 
> I was actually in doubt about those ;-)

On a quick test, I changed my script to use "--" and "---" for
EN/EM DASH chars.

The diff below is against both versions.

There are a couple of places where it got mathematically wrong, 
like this one:

	-operation over a temperature range of -40?C to +125?C.
	+operation over a temperature range of --40?C to +125?C.

On others, it is just a matter of personal taste. My personal opinion
is that, on most cases, a single "-" would be better.

Thanks,
Mauro

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 41a1eef0d0e7..469325255887 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -93,7 +93,7 @@ Contact:	Bj?rn Mork <bjorn@mork.no>
 Description:
 		- Bit 0: 16-bit NTB supported (set to 1)
 		- Bit 1: 32-bit NTB supported
-		- Bits 2 - 15: reserved (reset to zero; must be ignored by host)
+		- Bits 2 -- 15: reserved (reset to zero; must be ignored by host)
 
 What:		/sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
 Date:		May 2014
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 9b4b04039982..7a75f1f6e73c 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
     Extended Address Space Descriptor (.4)
       General Flags: Bit [0] Consumer/Producer:
 
-        * 1 - This device consumes this resource
-        * 0 - This device produces and consumes this resource
+        * 1 -- This device consumes this resource
+        * 0 -- This device produces and consumes this resource
 
 [5] ACPI 6.2, sec 19.6.43:
     ResourceUsage specifies whether the Memory range is consumed by
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index d76c6bfdc659..34a12b12df51 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
    43 }
 
 But the only part of ``rcu_prepare_for_idle()`` that really matters for
-this discussion are lines 37-39. We will therefore abbreviate this
+this discussion are lines 37--39. We will therefore abbreviate this
 function as follows:
 
 .. kernel-figure:: rcu_node-lock.svg
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a3493b34f3dd..a42dc3cf26bd 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
 stress-test suite. This stress-test suite is called ``rcutorture``.
 
 Although the need for ``rcutorture`` was no surprise, the current
-immense popularity of the Linux kernel is posing interesting-and perhaps
-unprecedented-validation challenges. To see this, keep in mind that
+immense popularity of the Linux kernel is posing interesting---and perhaps
+unprecedented---validation challenges. To see this, keep in mind that
 there are well over one billion instances of the Linux kernel running
 today, given Android smartphones, Linux-powered televisions, and
 servers. This number can be expected to increase sharply with the advent
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index b1692643718d..1a6dbda71ad6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -3,7 +3,7 @@ The Linux kernel user's and administrator's guide
 
 The following is a collection of user-oriented documents that have been
 added to the kernel over time.  There is, as yet, little overall order or
-organization here - this material was not written to be a single, coherent
+organization here --- this material was not written to be a single, coherent
 document!  With luck things will improve quickly over time.
 
 This initial section contains overall information, including the README
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index bd1d2fef78e8..0d185ba8b8b5 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -100,8 +100,8 @@ This has a number of options available:
      ``certs/signing_key.pem`` will disable the autogeneration of signing keys
      and allow the kernel modules to be signed with a key of your choosing.
      The string provided should identify a file containing both a private key
-     and its corresponding X.509 certificate in PEM form, or - on systems where
-     the OpenSSL ENGINE_pkcs11 is functional - a PKCS#11 URI as defined by
+     and its corresponding X.509 certificate in PEM form, or --- on systems where
+     the OpenSSL ENGINE_pkcs11 is functional --- a PKCS#11 URI as defined by
      RFC7512. In the latter case, the PKCS#11 URI should reference both a
      certificate and a private key.
 
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
index 00445adf8708..66c2c62c1cd4 100644
--- a/Documentation/admin-guide/ras.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -40,10 +40,10 @@ it causes data loss or system downtime.
 
 Among the monitoring measures, the most usual ones include:
 
-* CPU - detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory - add error correction logic (ECC) to detect and correct errors;
-* I/O - add CRC checksums for transferred data;
-* Storage - RAID, journal file systems, checksums,
+* CPU -- detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory -- add error correction logic (ECC) to detect and correct errors;
+* I/O -- add CRC checksums for transferred data;
+* Storage -- RAID, journal file systems, checksums,
   Self-Monitoring, Analysis and Reporting Technology (SMART).
 
 By monitoring the number of occurrences of error detections, it is possible
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index f691930e13c0..af699015d266 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -824,7 +824,7 @@ and look a little lower at the table. At its top you'll see a line starting with
 mainline, which most of the time will point to a pre-release with a version
 number like '5.8-rc2'. If that's the case, you'll want to use this mainline
 kernel for testing, as that where all fixes have to be applied first. Do not let
-that 'rc' scare you, these 'development kernels' are pretty reliable - and you
+that 'rc' scare you, these 'development kernels' are pretty reliable --- and you
 made a backup, as you were instructed above, didn't you?
 
 In about two out of every nine to ten weeks, mainline might point you to a
@@ -866,7 +866,7 @@ How to obtain a fresh Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 **Using a pre-compiled kernel**: This is often the quickest, easiest, and safest
-way for testing - especially is you are unfamiliar with the Linux kernel. The
+way for testing --- especially is you are unfamiliar with the Linux kernel. The
 problem: most of those shipped by distributors or add-on repositories are build
 from modified Linux sources. They are thus not vanilla and therefore often
 unsuitable for testing and issue reporting: the changes might cause the issue
@@ -1345,7 +1345,7 @@ about it to a chatroom or forum you normally hang out.
 
 **Be patient**: If you are really lucky you might get a reply to your report
 within a few hours. But most of the time it will take longer, as maintainers
-are scattered around the globe and thus might be in a different time zone - one
+are scattered around the globe and thus might be in a different time zone -- one
 where they already enjoy their night away from keyboard.
 
 In general, kernel developers will take one to five business days to respond to
@@ -1388,7 +1388,7 @@ Here are your duties in case you got replies to your report:
 
 **Check who you deal with**: Most of the time it will be the maintainer or a
 developer of the particular code area that will respond to your report. But as
-issues are normally reported in public it could be anyone that's replying -
+issues are normally reported in public it could be anyone that's replying ---
 including people that want to help, but in the end might guide you totally off
 track with their questions or requests. That rarely happens, but it's one of
 many reasons why it's wise to quickly run an internet search to see who you're
@@ -1716,7 +1716,7 @@ Maybe their test hardware broke, got replaced by something more fancy, or is so
 old that it's something you don't find much outside of computer museums
 anymore. Sometimes developer stops caring for their code and Linux at all, as
 something different in their life became way more important. In some cases
-nobody is willing to take over the job as maintainer - and nobody can be forced
+nobody is willing to take over the job as maintainer -- and nobody can be forced
 to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
 drivers nevertheless remain in the kernel: they are still useful for people and
 removing would be a regression.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 743a7c70fd83..639dd58518ca 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1285,7 +1285,7 @@ The soft lockup detector monitors CPUs for threads that are hogging the CPUs
 without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
 from running. The mechanism depends on the CPUs ability to respond to timer
 interrupts which are needed for the 'watchdog/N' threads to be woken up by
-the watchdog timer function, otherwise the NMI watchdog - if enabled - can
+the watchdog timer function, otherwise the NMI watchdog --- if enabled --- can
 detect a hard lockup condition.
 
 
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 8adffc26a2ec..381c571eb52c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
 groups of tests easier, as well as providing helpers to aid in writing new
 tests.
 
-If you're looking to verify the behaviour of the Kernel - particularly specific
-parts of the kernel - then you'll want to use KUnit or kselftest.
+If you're looking to verify the behaviour of the Kernel --- particularly specific
+parts of the kernel --- then you'll want to use KUnit or kselftest.
 
 
 The Difference Between KUnit and kselftest
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index c2d709467c68..ac5c9f1d2311 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -76,7 +76,7 @@ comments that look like this::
 
 The problem is the missing "*", which confuses the build system's
 simplistic idea of what C comment blocks look like.  This problem had been
-present since that comment was added in 2016 - a full four years.  Fixing
+present since that comment was added in 2016 --- a full four years.  Fixing
 it was a matter of adding the missing asterisks.  A quick look at the
 history for that file showed what the normal format for subject lines is,
 and ``scripts/get_maintainer.pl`` told me who should receive it.  The
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 8d650b4e2ce6..1d6e910c27df 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -4,11 +4,11 @@ FPGA Bridge
 API to implement a new FPGA bridge
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* struct fpga_bridge - The FPGA Bridge structure
-* struct fpga_bridge_ops - Low level Bridge driver ops
-* devm_fpga_bridge_create() - Allocate and init a bridge struct
-* fpga_bridge_register() - Register a bridge
-* fpga_bridge_unregister() - Unregister a bridge
+* struct fpga_bridge --- The FPGA Bridge structure
+* struct fpga_bridge_ops --- Low level Bridge driver ops
+* devm_fpga_bridge_create() --- Allocate and init a bridge struct
+* fpga_bridge_register() --- Register a bridge
+* fpga_bridge_unregister() --- Unregister a bridge
 
 .. kernel-doc:: include/linux/fpga/fpga-bridge.h
    :functions: fpga_bridge
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 4d926b452cb3..272161361c6a 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -101,12 +101,12 @@ in state.
 API for implementing a new FPGA Manager driver
 ----------------------------------------------
 
-* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
-* struct fpga_manager -  the FPGA manager struct
-* struct fpga_manager_ops -  Low level FPGA manager driver ops
-* devm_fpga_mgr_create() -  Allocate and init a manager struct
-* fpga_mgr_register() -  Register an FPGA manager
-* fpga_mgr_unregister() -  Unregister an FPGA manager
+* ``fpga_mgr_states`` ---  Values for :c:expr:`fpga_manager->state`.
+* struct fpga_manager ---  the FPGA manager struct
+* struct fpga_manager_ops ---  Low level FPGA manager driver ops
+* devm_fpga_mgr_create() ---  Allocate and init a manager struct
+* fpga_mgr_register() ---  Register an FPGA manager
+* fpga_mgr_unregister() ---  Unregister an FPGA manager
 
 .. kernel-doc:: include/linux/fpga/fpga-mgr.h
    :functions: fpga_mgr_states
diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
index fb4da4240e96..adc725855bad 100644
--- a/Documentation/driver-api/fpga/fpga-programming.rst
+++ b/Documentation/driver-api/fpga/fpga-programming.rst
@@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
 API for programming an FPGA
 ---------------------------
 
-* fpga_region_program_fpga() -  Program an FPGA
-* fpga_image_info() -  Specifies what FPGA image to program
-* fpga_image_info_alloc() -  Allocate an FPGA image info struct
-* fpga_image_info_free() -  Free an FPGA image info struct
+* fpga_region_program_fpga() ---  Program an FPGA
+* fpga_image_info() ---  Specifies what FPGA image to program
+* fpga_image_info_alloc() ---  Allocate an FPGA image info struct
+* fpga_image_info_free() ---  Free an FPGA image info struct
 
 .. kernel-doc:: drivers/fpga/fpga-region.c
    :functions: fpga_region_program_fpga
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index 2636a27c11b2..6c0c2541de04 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
 API to add a new FPGA region
 ----------------------------
 
-* struct fpga_region - The FPGA region struct
-* devm_fpga_region_create() - Allocate and init a region struct
-* fpga_region_register() -  Register an FPGA region
-* fpga_region_unregister() -  Unregister an FPGA region
+* struct fpga_region --- The FPGA region struct
+* devm_fpga_region_create() --- Allocate and init a region struct
+* fpga_region_register() ---  Register an FPGA region
+* fpga_region_unregister() ---  Unregister an FPGA region
 
 The FPGA region's probe function will need to get a reference to the FPGA
 Manager it will be using to do the programming.  This usually would happen
 during the region's probe function.
 
-* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
-* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
+* fpga_mgr_get() --- Get a reference to an FPGA manager, raise ref count
+* of_fpga_mgr_get() ---  Get a reference to an FPGA manager, raise ref count,
   given a device node.
-* fpga_mgr_put() - Put an FPGA manager
+* fpga_mgr_put() --- Put an FPGA manager
 
 The FPGA region will need to specify which bridges to control while programming
 the FPGA.  The region driver can build a list of bridges during probe time
@@ -66,11 +66,11 @@ the list of bridges to program just before programming
 (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
 following APIs to handle building or tearing down that list.
 
-* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list
-* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
+* of_fpga_bridge_get_to_list() --- Get a ref of an FPGA bridge, add it to a
   list, given a device node
-* fpga_bridges_put() - Given a list of bridges, put them
+* fpga_bridges_put() --- Given a list of bridges, put them
 
 .. kernel-doc:: include/linux/fpga/fpga-region.h
    :functions: fpga_region
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 24569ff0cf79..906dfc10b7ef 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -2,11 +2,11 @@
 Buffers
 =======
 
-* struct iio_buffer - general buffer structure
-* :c:func:`iio_validate_scan_mask_onehot` - Validates that exactly one channel
+* struct iio_buffer --- general buffer structure
+* :c:func:`iio_validate_scan_mask_onehot` --- Validates that exactly one channel
   is selected
-* :c:func:`iio_buffer_get` - Grab a reference to the buffer
-* :c:func:`iio_buffer_put` - Release the reference to the buffer
+* :c:func:`iio_buffer_get` --- Grab a reference to the buffer
+* :c:func:`iio_buffer_put` --- Release the reference to the buffer
 
 The Industrial I/O core offers a way for continuous data capture based on a
 trigger source. Multiple data channels can be read at once from
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index 75986358fc02..06969fde2086 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -8,11 +8,11 @@ software buffer for data. The implementation can be found under
 :file:`drivers/iio/buffer/hw-consumer.c`
 
 
-* struct iio_hw_consumer - Hardware consumer structure
-* :c:func:`iio_hw_consumer_alloc` - Allocate IIO hardware consumer
-* :c:func:`iio_hw_consumer_free` - Free IIO hardware consumer
-* :c:func:`iio_hw_consumer_enable` - Enable IIO hardware consumer
-* :c:func:`iio_hw_consumer_disable` - Disable IIO hardware consumer
+* struct iio_hw_consumer --- Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` --- Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` --- Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` --- Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` --- Disable IIO hardware consumer
 
 
 HW consumer setup
diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst
index 7c37b2afa1ad..49831ff466c5 100644
--- a/Documentation/driver-api/iio/triggered-buffers.rst
+++ b/Documentation/driver-api/iio/triggered-buffers.rst
@@ -7,10 +7,10 @@ Now that we know what buffers and triggers are let's see how they work together.
 IIO triggered buffer setup
 ==========================
 
-* :c:func:`iio_triggered_buffer_setup` - Setup triggered buffer and pollfunc
-* :c:func:`iio_triggered_buffer_cleanup` - Free resources allocated by
+* :c:func:`iio_triggered_buffer_setup` --- Setup triggered buffer and pollfunc
+* :c:func:`iio_triggered_buffer_cleanup` --- Free resources allocated by
   :c:func:`iio_triggered_buffer_setup`
-* struct iio_buffer_setup_ops - buffer setup related callbacks
+* struct iio_buffer_setup_ops --- buffer setup related callbacks
 
 A typical triggered buffer setup looks like this::
 
diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst
index a5d1fc15747c..5b3d475bc871 100644
--- a/Documentation/driver-api/iio/triggers.rst
+++ b/Documentation/driver-api/iio/triggers.rst
@@ -2,11 +2,11 @@
 Triggers
 ========
 
-* struct iio_trigger - industrial I/O trigger device
-* :c:func:`devm_iio_trigger_alloc` - Resource-managed iio_trigger_alloc
-* :c:func:`devm_iio_trigger_register` - Resource-managed iio_trigger_register
+* struct iio_trigger --- industrial I/O trigger device
+* :c:func:`devm_iio_trigger_alloc` --- Resource-managed iio_trigger_alloc
+* :c:func:`devm_iio_trigger_register` --- Resource-managed iio_trigger_register
   iio_trigger_unregister
-* :c:func:`iio_trigger_validate_own_device` - Check if a trigger and IIO
+* :c:func:`iio_trigger_validate_own_device` --- Check if a trigger and IIO
   device belong to the same device
 
 In many situations it is useful for a driver to be able to capture data based
@@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver::
 IIO trigger ops
 ===============
 
-* struct iio_trigger_ops - operations structure for an iio_trigger.
+* struct iio_trigger_ops --- operations structure for an iio_trigger.
 
 Notice that a trigger has a set of operations attached:
 
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index 29eb9230b7a9..e07e0d39c7f0 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -4,7 +4,7 @@ The Linux driver implementer's API guide
 
 The kernel offers a wide variety of interfaces to support the development
 of device drivers.  This document is an only somewhat organized collection
-of some of those interfaces - it will hopefully get better over time!  The
+of some of those interfaces --- it will hopefully get better over time!  The
 available subsections can be seen below.
 
 .. class:: toc-title
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index abb454302ac5..c3821d82df17 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -458,8 +458,8 @@ Add a way to test video
 
 Currently, vidtv can only encode PCM audio. It would be great to implement
 a barebones version of MPEG-2 video encoding so we can also test video. The
-first place to look into is *ISO 13818-2: Information technology - Generic
-coding of moving pictures and associated audio information - Part 2: Video*,
+first place to look into is *ISO 13818-2: Information technology --- Generic
+coding of moving pictures and associated audio information --- Part 2: Video*,
 which covers the encoding of compressed video in MPEG Transport Streams.
 
 This might optionally use the Video4Linux2 Test Pattern Generator, v4l2-tpg,
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index dd91a495e02e..1d2d9cd40def 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -91,7 +91,7 @@ Bit      Description
 	   0  0	  Initial state. Reads return zeroes; Premap = Postmap
 	   0  1	  Zero state: Reads return zeroes
 	   1  0	  Error state: Reads fail; Writes clear 'E' bit
-	   1  1	  Normal Block - has valid postmap
+	   1  1	  Normal Block -- has valid postmap
 	   == ==  ====================================================
 
 29 - 0	 Mappings to internal 'postmap' blocks
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 19d2cf477fc3..9b0e9abf8f88 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -42,7 +42,7 @@ areas on disk for fast writing, we divide  the log into segments and use a
 segment cleaner to compress the live information from heavily fragmented
 segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
 implementation of a log-structured file system", ACM Trans. Computer Systems
-10, 1, 26-52.
+10, 1, 26--52.
 
 Wandering Tree Problem
 ----------------------
diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
index b3ef81475cf8..051282bd88b7 100644
--- a/Documentation/hwmon/tmp103.rst
+++ b/Documentation/hwmon/tmp103.rst
@@ -21,10 +21,10 @@ Description
 The TMP103 is a digital output temperature sensor in a four-ball
 wafer chip-scale package (WCSP). The TMP103 is capable of reading
 temperatures to a resolution of 1?C. The TMP103 is specified for
-operation over a temperature range of -40?C to +125?C.
+operation over a temperature range of --40?C to +125?C.
 
 Resolution: 8 Bits
-Accuracy: ?1?C Typ (-10?C to +100?C)
+Accuracy: ?1?C Typ (--10?C to +100?C)
 
 The driver provides the common sysfs-interface for temperatures (see
 Documentation/hwmon/sysfs-interface.rst under Temperatures).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 11cd806ea3a4..7ae88aa57d98 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -30,7 +30,7 @@ tree, as well as links to the full license text.
 User-oriented documentation
 ---------------------------
 
-The following manuals are written for *users* of the kernel - those who are
+The following manuals are written for *users* of the kernel --- those who are
 trying to get it to work optimally on a given system.
 
 .. toctree::
@@ -90,7 +90,7 @@ Kernel API documentation
 These books get into the details of how specific kernel subsystems work
 from the point of view of a kernel developer.  Much of the information here
 is taken directly from the kernel source, with supplemental material added
-as needed (or at least as we managed to add it - probably *not* all that is
+as needed (or at least as we managed to add it --- probably *not* all that is
 needed).
 
 .. toctree::
diff --git a/Documentation/infiniband/tag_matching.rst b/Documentation/infiniband/tag_matching.rst
index b89528a31d10..2c26f76e43f9 100644
--- a/Documentation/infiniband/tag_matching.rst
+++ b/Documentation/infiniband/tag_matching.rst
@@ -8,8 +8,8 @@ match the following source and destination parameters:
 
 *	Communicator
 *	User tag - wild card may be specified by the receiver
-*	Source rank - wild car may be specified by the receiver
-*	Destination rank - wild
+*	Source rank -- wild car may be specified by the receiver
+*	Destination rank -- wild
 
 The ordering rules require that when more than one pair of send and receive
 message envelopes may match, the pair that includes the earliest posted-send
diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
index 64024c77c9ca..e3e52b0e6b5e 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
@@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the
 driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
 option. For example::
 
-  ethtool -K [adapter] ntuple [off|on]
+  ethtool --K [adapter] ntuple [off|on]
 
 If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
 TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
@@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 2. Enable HW TC offload on interface::
 
diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
index 25e98494b385..44d2f85738b1 100644
--- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
@@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
 Totals must be equal or less than port speed.
 
 For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
-monitoring tools such as ifstat or sar -n DEV [interval] [number of samples]
+monitoring tools such as ifstat or sar --n DEV [interval] [number of samples]
 
 NOTE:
   Setting up channels via ethtool (ethtool -L) is not supported when the
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 545f8ab51f1a..05615b3021bb 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -22,7 +22,7 @@ RISC-V Linux Kernel 64bit
 =========================
 
 The RISC-V privileged architecture document states that the 64bit addresses
-"must have bits 63-48 all equal to bit 47, or else a page-fault exception will
+"must have bits 63--48 all equal to bit 47, or else a page-fault exception will
 occur.": that splits the virtual address space into 2 halves separated by a very
 big hole, the lower half is where the userspace resides, the upper half is where
 the RISC-V Linux Kernel resides.
diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
index 0ff353ecf24e..b261ec2ab2ef 100644
--- a/Documentation/scheduler/sched-deadline.rst
+++ b/Documentation/scheduler/sched-deadline.rst
@@ -515,7 +515,7 @@ Deadline Task Scheduling
       pp 760-768, 2005.
   10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of
        Periodic Task Systems on Multiprocessors. Real-Time Systems Journal,
-       vol. 25, no. 2-3, pp. 187-205, 2003.
+       vol. 25, no. 2--3, pp. 187--205, 2003.
   11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for
        Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011.
        http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 6e07b78bd39d..7b8e6738ff9e 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -51,7 +51,7 @@ ISO 13818-1
 ===========
 
 
-:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology - Generic coding of moving pictures and associated audio information: Systems"
+:title:     ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information technology --- Generic coding of moving pictures and associated audio information: Systems"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -61,7 +61,7 @@ ISO 13818-2
 ===========
 
 
-:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology - Generic coding of moving pictures and associated audio information: Video"
+:title:     ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information technology --- Generic coding of moving pictures and associated audio information: Video"
 
 :author:    International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch)
 
@@ -150,7 +150,7 @@ ITU-T.81
 ========
 
 
-:title:     ITU-T Recommendation T.81 "Information Technology - Digital Compression and Coding of Continous-Tone Still Images - Requirements and Guidelines"
+:title:     ITU-T Recommendation T.81 "Information Technology --- Digital Compression and Coding of Continous-Tone Still Images --- Requirements and Guidelines"
 
 :author:    International Telecommunication Union (http://www.itu.int)
 
@@ -310,7 +310,7 @@ ISO 12232:2006
 ==============
 
 
-:title:     Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
+:title:     Photography --- Digital still cameras --- Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index
 
 :author:    International Organization for Standardization (http://www.iso.org)
 
diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/running-nested-guests.rst
index e9dff3fea055..8b83b86560da 100644
--- a/Documentation/virt/kvm/running-nested-guests.rst
+++ b/Documentation/virt/kvm/running-nested-guests.rst
@@ -26,12 +26,12 @@ this document is built on this example)::
 
 Terminology:
 
-- L0 - level-0; the bare metal host, running KVM
+- L0 -- level-0; the bare metal host, running KVM
 
-- L1 - level-1 guest; a VM running on L0; also called the "guest
+- L1 -- level-1 guest; a VM running on L0; also called the "guest
   hypervisor", as it itself is capable of running KVM.
 
-- L2 - level-2 guest; a VM running on L1, this is the "nested guest"
+- L2 -- level-2 guest; a VM running on L1, this is the "nested guest"
 
 .. note:: The above diagram is modelled after the x86 architecture;
           s390x, ppc64 and other architectures are likely to have
@@ -39,7 +39,7 @@ Terminology:
 
           For example, s390x always has an LPAR (LogicalPARtition)
           hypervisor running on bare metal, adding another layer and
-          resulting in at least four levels in a nested setup - L0 (bare
+          resulting in at least four levels in a nested setup --- L0 (bare
           metal, running the LPAR hypervisor), L1 (host hypervisor), L2
           (guest hypervisor), L3 (nested guest).
 
@@ -167,11 +167,11 @@ Enabling "nested" (s390x)
     $ modprobe kvm nested=1
 
 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
-          with the ``nested`` paramter - i.e. to be able to enable
+          with the ``nested`` paramter --- i.e. to be able to enable
           ``nested``, the ``hpage`` parameter *must* be disabled.
 
 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
-   feature - with QEMU, this can be done by using "host passthrough"
+   feature --- with QEMU, this can be done by using "host passthrough"
    (via the command-line ``-cpu host``).
 
 3. Now the KVM module can be loaded in the L1 (guest hypervisor)::



^ permalink raw reply related	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 11:55     ` Mauro Carvalho Chehab
                       ` (5 preceding siblings ...)
  (?)
@ 2021-05-10 12:29     ` beroal
  -1 siblings, 0 replies; 219+ messages in thread
From: beroal @ 2021-05-10 12:29 UTC (permalink / raw)
  To: linux-f2fs-devel

On 10.05.21 14:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well, e. g. it is limited
> for those chars:
>
> 	- U+2010 ('‐'): HYPHEN
> 	- U+00ad ('­'): SOFT HYPHEN
> 	- U+2013 ('–'): EN DASH
> 	- U+2014 ('—'): EM DASH
>
> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+00b4 ('´'): ACUTE ACCENT
>
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
>
> 	- U+00d7 ('×'): MULTIPLICATION SIGN
> 	- U+2212 ('−'): MINUS SIGN
>
> 	- U+2217 ('∗'): ASTERISK OPERATOR
> 	  (this one used as a pointer reference like "*foo" on C code
> 	   example inside a document converted from LaTeX)
>
> 	- U+00bb ('»'): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
> 	  (this one also used wrongly on an ABI file, meaning '>')
>
> 	- U+00a0 (' '): NO-BREAK SPACE
> 	- U+feff (''): ZERO WIDTH NO-BREAK SPACE
>
> Using the above symbols will just trick tools like grep for no good
> reason.
Since when is ASCII able to represent dashes and all those quotation 
marks? As far as I remember, these characters were the main reason to 
ditch ASCII in favor of national text encodings.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
  2021-05-10 10:26   ` Mauro Carvalho Chehab
  (?)
@ 2021-05-10 12:36     ` Liviu Dudau
  -1 siblings, 0 replies; 219+ messages in thread
From: Liviu Dudau @ 2021-05-10 12:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Thomas Zimmermann, Jonathan Corbet,
	dri-devel, linux-kernel, David Airlie, James (Qian) Wang,
	Rodrigo Vivi, Mali DP Maintainers, Mihail Atanassov, intel-gfx

On Mon, May 10, 2021 at 12:26:56PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/gpu/i915.rst       | 2 +-
>  Documentation/gpu/komeda-kms.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 486c720f3890..2cbf54460b48 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -361,7 +361,7 @@ Locking Guidelines
>  	  real bad.
>  
>  #. Do not nest different lru/memory manager locks within each other.
> -   Take them in turn to update memory allocations, relying on the object’s
> +   Take them in turn to update memory allocations, relying on the object's
>     dma_resv ww_mutex to serialize against other operations.
>  
>  #. The suggestion for lru/memory managers locks is that they are small
> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
> index eb693c857e2d..c2067678e92c 100644
> --- a/Documentation/gpu/komeda-kms.rst
> +++ b/Documentation/gpu/komeda-kms.rst
> @@ -324,7 +324,7 @@ the control-abilites of device.
>  
>  We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
>  pipelines. Since komeda is not for D71 only but also intended for later products,
> -of course we’d better share as much as possible between different products. To
> +of course we'd better share as much as possible between different products. To
>  achieve this, split the komeda device into two layers: CORE and CHIP.
>  
>  -   CORE: for common features and capabilities handling.

Acked-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> -- 
> 2.30.2
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
@ 2021-05-10 12:36     ` Liviu Dudau
  0 siblings, 0 replies; 219+ messages in thread
From: Liviu Dudau @ 2021-05-10 12:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Jonathan Corbet, David Airlie, intel-gfx, Linux Doc Mailing List,
	linux-kernel, dri-devel, James (Qian) Wang, Thomas Zimmermann,
	Rodrigo Vivi, Mali DP Maintainers, Mihail Atanassov

On Mon, May 10, 2021 at 12:26:56PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/gpu/i915.rst       | 2 +-
>  Documentation/gpu/komeda-kms.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 486c720f3890..2cbf54460b48 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -361,7 +361,7 @@ Locking Guidelines
>  	  real bad.
>  
>  #. Do not nest different lru/memory manager locks within each other.
> -   Take them in turn to update memory allocations, relying on the object’s
> +   Take them in turn to update memory allocations, relying on the object's
>     dma_resv ww_mutex to serialize against other operations.
>  
>  #. The suggestion for lru/memory managers locks is that they are small
> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
> index eb693c857e2d..c2067678e92c 100644
> --- a/Documentation/gpu/komeda-kms.rst
> +++ b/Documentation/gpu/komeda-kms.rst
> @@ -324,7 +324,7 @@ the control-abilites of device.
>  
>  We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
>  pipelines. Since komeda is not for D71 only but also intended for later products,
> -of course we’d better share as much as possible between different products. To
> +of course we'd better share as much as possible between different products. To
>  achieve this, split the komeda device into two layers: CORE and CHIP.
>  
>  -   CORE: for common features and capabilities handling.

Acked-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> -- 
> 2.30.2
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 44/53] docs: gpu: avoid using UTF-8 chars
@ 2021-05-10 12:36     ` Liviu Dudau
  0 siblings, 0 replies; 219+ messages in thread
From: Liviu Dudau @ 2021-05-10 12:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Jonathan Corbet, David Airlie, intel-gfx, Linux Doc Mailing List,
	linux-kernel, dri-devel, James (Qian) Wang, Thomas Zimmermann,
	Mali DP Maintainers, Mihail Atanassov

On Mon, May 10, 2021 at 12:26:56PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/gpu/i915.rst       | 2 +-
>  Documentation/gpu/komeda-kms.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 486c720f3890..2cbf54460b48 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -361,7 +361,7 @@ Locking Guidelines
>  	  real bad.
>  
>  #. Do not nest different lru/memory manager locks within each other.
> -   Take them in turn to update memory allocations, relying on the object’s
> +   Take them in turn to update memory allocations, relying on the object's
>     dma_resv ww_mutex to serialize against other operations.
>  
>  #. The suggestion for lru/memory managers locks is that they are small
> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
> index eb693c857e2d..c2067678e92c 100644
> --- a/Documentation/gpu/komeda-kms.rst
> +++ b/Documentation/gpu/komeda-kms.rst
> @@ -324,7 +324,7 @@ the control-abilites of device.
>  
>  We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
>  pipelines. Since komeda is not for D71 only but also intended for later products,
> -of course we’d better share as much as possible between different products. To
> +of course we'd better share as much as possible between different products. To
>  achieve this, split the komeda device into two layers: CORE and CHIP.
>  
>  -   CORE: for common features and capabilities handling.

Acked-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> -- 
> 2.30.2
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 11:55     ` Mauro Carvalho Chehab
                         ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 13:16       ` Edward Cree
  -1 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because — even in
 monospace fonts — they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions — like en dashes — are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('×'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with × or — in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:16       ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because — even in
 monospace fonts — they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions — like en dashes — are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('×'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with × or — in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:16       ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because — even in
 monospace fonts — they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions — like en dashes — are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('×'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with × or — in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:16       ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because — even in
 monospace fonts — they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions — like en dashes — are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('×'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with × or — in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:16       ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because — even in
 monospace fonts — they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions — like en dashes — are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('×'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with × or — in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:16       ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('—'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because — even in
 monospace fonts — they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions — like en dashes — are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('×'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with × or — in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:16       ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:16 UTC (permalink / raw)
  To: intel-wired-lan

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> The main point on this series is to replace just the occurrences
> where ASCII represents the symbol equally well

> 	- U+2014 ('?'): EM DASH
Em dash is not the same thing as hyphen-minus, and the latter does not
 serve 'equally well'.  People use em dashes because ? even in
 monospace fonts ? they make text easier to read and comprehend, when
 used correctly.
I accept that some of the other distinctions ? like en dashes ? are
 needlessly pedantic (though I don't doubt there is someone out there
 who will gladly defend them with the same fervour with which I argue
 for the em dash) and I wouldn't take the trouble to use them myself;
 but I think there is a reasonable assumption that when someone goes
 to the effort of using a Unicode punctuation mark that is semantic
 (rather than merely typographical), they probably had a reason for
 doing so.

> 	- U+2018 ('?'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('?'): RIGHT SINGLE QUOTATION MARK
> 	- U+201c ('?'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('?'): RIGHT DOUBLE QUOTATION MARK
(These are purely typographic, I have no problem with dumping them.)

> 	- U+00d7 ('?'): MULTIPLICATION SIGN
Presumably this is appearing in mathematical formulae, in which case
 changing it to 'x' loses semantic information.

> Using the above symbols will just trick tools like grep for no good
> reason.
NBSP, sure.  That one's probably an artefact of some document format
 conversion somewhere along the line, anyway.
But what kinds of things with ? or ? in are going to be grept for?

If there are em dashes lying around that semantically _should_ be
 hyphen-minus (one of your patches I've seen, for instance, fixes an
 *en* dash moonlighting as the option character in an `ethtool`
 command line), then sure, convert them.
But any time someone is using a Unicode character to *express
 semantics*, even if you happen to think the semantic distinction
 involved is a pedantic or unimportant one, I think you need an
 explicit grep case to justify ASCIIfying it.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 05/53] docs: hwmon: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 05/53] docs: hwmon: " Mauro Carvalho Chehab
@ 2021-05-10 13:30   ` Guenter Roeck
  0 siblings, 0 replies; 219+ messages in thread
From: Guenter Roeck @ 2021-05-10 13:30 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Charles Hsu,
	Jean Delvare, linux-hwmon, linux-kernel

On Mon, May 10, 2021 at 12:26:17PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2010 ('‐'): HYPHEN
> 	- U+2013 ('–'): EN DASH
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Makes perfect sense for the changes below. I don't know what the plan is,
so I applied the patch to hwmon-next.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 13:16       ` Edward Cree
                           ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('—'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with × or — in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep × Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('—'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with × or — in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep × Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('—'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with × or — in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep × Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('—'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with × or — in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep × Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('—'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with × or — in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep × Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('—'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('×'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with × or — in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep × Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF × 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 × 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 × 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 × 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 × 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 × 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 × 384, so the driver returns the cropping size 608 × 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 × 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 × 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:38         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-10 13:38 UTC (permalink / raw)
  To: intel-wired-lan

Em Mon, 10 May 2021 14:16:16 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well  
> 
> > 	- U+2014 ('?'): EM DASH  
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because ? even in
>  monospace fonts ? they make text easier to read and comprehend, when
>  used correctly.

True, but if you look at the diff, on several places, IMHO a single
hyphen would make more sensus. Maybe those places came from a converted
doc.

> I accept that some of the other distinctions ? like en dashes ? are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.
> 
> > 	- U+2018 ('?'): LEFT SINGLE QUOTATION MARK
> > 	- U+2019 ('?'): RIGHT SINGLE QUOTATION MARK
> > 	- U+201c ('?'): LEFT DOUBLE QUOTATION MARK
> > 	- U+201d ('?'): RIGHT DOUBLE QUOTATION MARK  
> (These are purely typographic, I have no problem with dumping them.)
> 
> > 	- U+00d7 ('?'): MULTIPLICATION SIGN  
> Presumably this is appearing in mathematical formulae, in which case
>  changing it to 'x' loses semantic information.
> 
> > Using the above symbols will just trick tools like grep for no good
> > reason.  
> NBSP, sure.  That one's probably an artefact of some document format
>  conversion somewhere along the line, anyway.
> But what kinds of things with ? or ? in are going to be grept for?

Actually, on almost all places, those aren't used inside math formulae, but
instead, they describe video some resolutions:

	$ git grep ? Documentation/
	Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml:title: ASUS Z00T TM5P5 NT35596 5.5" 1080?1920 LCD Panel
	Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml:        # LG ACX467AKM-7 4.95" 1080?1920 LCD Panel
	Documentation/devicetree/bindings/sound/tlv320adcx140.yaml:      1 - Mic bias is set to VREF ? 1.096
	Documentation/userspace-api/media/v4l/crop.rst:of 16 ? 16 pixels. The source cropping rectangle is set to defaults,
	Documentation/userspace-api/media/v4l/crop.rst:which are also the upper limit in this example, of 640 ? 400 pixels at
	Documentation/userspace-api/media/v4l/crop.rst:offset 0, 0. An application requests an image size of 300 ? 225 pixels,
	Documentation/userspace-api/media/v4l/crop.rst:The driver sets the image size to the closest possible values 304 ? 224,
	Documentation/userspace-api/media/v4l/crop.rst:is 608 ? 224 (224 ? 2:1 would exceed the limit 400). The offset 0, 0 is
	Documentation/userspace-api/media/v4l/crop.rst:rectangle of 608 ? 456 pixels. The present scaling factors limit
	Documentation/userspace-api/media/v4l/crop.rst:cropping to 640 ? 384, so the driver returns the cropping size 608 ? 384
	Documentation/userspace-api/media/v4l/crop.rst:and adjusts the image size to closest possible 304 ? 192.
	Documentation/userspace-api/media/v4l/diff-v4l.rst:size bitmap of 1024 ? 625 bits. Struct :c:type:`v4l2_window`
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       Assuming pixel aspect 1/1 this could be for example a 640 ? 480
	Documentation/userspace-api/media/v4l/vidioc-cropcap.rst:       rectangle for NTSC, a 768 ? 576 rectangle for PAL and SECAM

it is a way more likely that, if someone wants to grep, they would be 
doing something like this, in order to get video resolutions:

	$ git grep -E "\b[1-9][0-9]+\s*x\s*[0-9]+\b" Documentation/
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure:Description:        When read the mouse returns a 30x30 pixel image of the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Provides access to the binary "24x7 catalog" provided by the
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-	catalog.h
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               Exposes the "version" field of the 24x7 catalog. This is also
	Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7:               HCALLs to retrieve hv-24x7 pmu event counter data.
	Documentation/ABI/testing/sysfs-bus-vfio-mdev:          "2 heads, 512M FB, 2560x1600 maximum resolution"
	Documentation/ABI/testing/sysfs-driver-wacom:           of the device. The image is a 64x32 pixel 4-bit gray image. The
	Documentation/ABI/testing/sysfs-driver-wacom:           1024 byte binary is split up into 16x 64 byte chunks. Each 64
	Documentation/ABI/testing/sysfs-driver-wacom:           image has to contain 256 bytes (64x32 px 1 bit colour).
	Documentation/admin-guide/edid.rst:commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
	Documentation/admin-guide/edid.rst:1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
	Documentation/admin-guide/edid.rst:If you want to create your own EDID file, copy the file 1024x768.S,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1024x768.bin, edid/1280x1024.bin,
	Documentation/admin-guide/kernel-parameters.txt:                        edid/1680x1050.bin, or edid/1920x1080.bin is given
	Documentation/admin-guide/kernel-parameters.txt:                        2 - The VGA Shield is attached (1024x768)
	Documentation/admin-guide/media/dvb_intro.rst:signal encoded at a resolution of 768x576 24-bit color pixels over 25
	Documentation/admin-guide/media/imx.rst:1280x960 input frame to 640x480, and then /2 downscale in both
	Documentation/admin-guide/media/imx.rst:dimensions to 320x240 (assumes ipu1_csi0 is linked to ipu1_csi0_mux):
	Documentation/admin-guide/media/imx.rst:   media-ctl -V "'ipu1_csi0_mux':2[fmt:UYVY2X8/1280x960]"

which won't get the above, due to the usage of the UTF-8 alternative.

In any case, replacing all the above by 'x' seems to be the right thing,
at least on my eyes.

> If there are em dashes lying around that semantically _should_ be
>  hyphen-minus (one of your patches I've seen, for instance, fixes an
>  *en* dash moonlighting as the option character in an `ethtool`
>  command line), then sure, convert them.
> But any time someone is using a Unicode character to *express
>  semantics*, even if you happen to think the semantic distinction
>  involved is a pedantic or unimportant one, I think you need an
>  explicit grep case to justify ASCIIfying it.

Yeah, in the case of hyphen/dash it seems to make sense to double check
it.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 11:55     ` Mauro Carvalho Chehab
                         ` (3 preceding siblings ...)
  (?)
@ 2021-05-10 13:49       ` David Woodhouse
  -1 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 13:49 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8. 
> 
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> character doesn't do any good.
> 
> Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> someone tries to use grep[1].

Replacing those makes sense. But replacing emdashes — which are a
distinct character that has no direct replacement in ASCII and which
people do *deliberately* use instead of hyphen-minus — does not.

Perhaps stick to those two, and any cases where an emdash or endash has
been used where U+002D HYPHEN-MINUS *should* have been used.

And please fix your cover letter which made no reference to 'grep', and
only presented a completely bogus argument for the change instead.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:49       ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 13:49 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86


[-- Attachment #1.1: Type: text/plain, Size: 936 bytes --]

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8. 
> 
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> character doesn't do any good.
> 
> Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> someone tries to use grep[1].

Replacing those makes sense. But replacing emdashes — which are a
distinct character that has no direct replacement in ASCII and which
people do *deliberately* use instead of hyphen-minus — does not.

Perhaps stick to those two, and any cases where an emdash or endash has
been used where U+002D HYPHEN-MINUS *should* have been used.

And please fix your cover letter which made no reference to 'grep', and
only presented a completely bogus argument for the change instead.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:49       ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 13:49 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8. 
> 
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> character doesn't do any good.
> 
> Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> someone tries to use grep[1].

Replacing those makes sense. But replacing emdashes — which are a
distinct character that has no direct replacement in ASCII and which
people do *deliberately* use instead of hyphen-minus — does not.

Perhaps stick to those two, and any cases where an emdash or endash has
been used where U+002D HYPHEN-MINUS *should* have been used.

And please fix your cover letter which made no reference to 'grep', and
only presented a completely bogus argument for the change instead.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:49       ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 13:49 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86


[-- Attachment #1.1: Type: text/plain, Size: 936 bytes --]

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8. 
> 
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> character doesn't do any good.
> 
> Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> someone tries to use grep[1].

Replacing those makes sense. But replacing emdashes — which are a
distinct character that has no direct replacement in ASCII and which
people do *deliberately* use instead of hyphen-minus — does not.

Perhaps stick to those two, and any cases where an emdash or endash has
been used where U+002D HYPHEN-MINUS *should* have been used.

And please fix your cover letter which made no reference to 'grep', and
only presented a completely bogus argument for the change instead.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:49       ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 13:49 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity


[-- Attachment #1.1: Type: text/plain, Size: 936 bytes --]

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8. 
> 
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> character doesn't do any good.
> 
> Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> someone tries to use grep[1].

Replacing those makes sense. But replacing emdashes — which are a
distinct character that has no direct replacement in ASCII and which
people do *deliberately* use instead of hyphen-minus — does not.

Perhaps stick to those two, and any cases where an emdash or endash has
been used where U+002D HYPHEN-MINUS *should* have been used.

And please fix your cover letter which made no reference to 'grep', and
only presented a completely bogus argument for the change instead.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:49       ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-10 13:49 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8. 
> 
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> character doesn't do any good.
> 
> Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> someone tries to use grep[1].

Replacing those makes sense. But replacing emdashes ? which are a
distinct character that has no direct replacement in ASCII and which
people do *deliberately* use instead of hyphen-minus ? does not.

Perhaps stick to those two, and any cases where an emdash or endash has
been used where U+002D HYPHEN-MINUS *should* have been used.

And please fix your cover letter which made no reference to 'grep', and
only presented a completely bogus argument for the change instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210510/6929b0ec/attachment-0001.bin>

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 41/53] docs: ABI: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 41/53] docs: ABI: " Mauro Carvalho Chehab
@ 2021-05-10 13:53   ` Guenter Roeck
  0 siblings, 0 replies; 219+ messages in thread
From: Guenter Roeck @ 2021-05-10 13:53 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Benson Leung,
	Enric Balletbo i Serra, Greg Kroah-Hartman, Guenter Roeck,
	Steven Price, Sudeep Holla, Suzuki K Poulose, Tom Rix,
	Vaibhav Jain, linux-kernel

On Mon, May 10, 2021 at 3:27 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
>         - U+2013 ('–'): EN DASH
>         - U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
>         - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Reviewed-by: Guenter Roeck <groeck@chromium.org>

> ---
>  .../ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar  | 2 +-
>  Documentation/ABI/testing/sysfs-class-net-cdc_ncm             | 2 +-
>  Documentation/ABI/testing/sysfs-devices-platform-ipmi         | 2 +-
>  Documentation/ABI/testing/sysfs-devices-platform-trackpoint   | 2 +-
>  Documentation/ABI/testing/sysfs-devices-soc                   | 4 ++--
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar b/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
> index 57a037791403..a7fb8f1169f2 100644
> --- a/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
> +++ b/Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar
> @@ -29,7 +29,7 @@ KernelVersion:        4.2
>  Description:
>                 This allows you to control each LED segment. If the
>                 lightbar is already running one of the automatic
> -               sequences, you probably won’t see anything change because
> +               sequences, you probably won't see anything change because
>                 your color setting will be almost immediately replaced.
>                 To get useful results, you should stop the lightbar
>                 sequence first.
> diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
> index 06416d0e163d..41a1eef0d0e7 100644
> --- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
> +++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
> @@ -93,7 +93,7 @@ Contact:      Bjørn Mork <bjorn@mork.no>
>  Description:
>                 - Bit 0: 16-bit NTB supported (set to 1)
>                 - Bit 1: 32-bit NTB supported
> -               - Bits 2 – 15: reserved (reset to zero; must be ignored by host)
> +               - Bits 2 - 15: reserved (reset to zero; must be ignored by host)
>
>  What:          /sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
>  Date:          May 2014
> diff --git a/Documentation/ABI/testing/sysfs-devices-platform-ipmi b/Documentation/ABI/testing/sysfs-devices-platform-ipmi
> index 07df0ddc0b69..3935cdedea0e 100644
> --- a/Documentation/ABI/testing/sysfs-devices-platform-ipmi
> +++ b/Documentation/ABI/testing/sysfs-devices-platform-ipmi
> @@ -52,7 +52,7 @@ Date:         Mar, 2006
>  KernelVersion: v2.6.17
>  Contact:       openipmi-developer@lists.sourceforge.net
>  Description:
> -               (RO) Lists the IPMI ‘logical device’ commands and functions
> +               (RO) Lists the IPMI 'logical device' commands and functions
>                 that the controller supports that are in addition to the
>                 mandatory IPM and Application commands.
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
> index df11901a6b3d..82a38ac0435c 100644
> --- a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
> +++ b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
> @@ -105,7 +105,7 @@ KernelVersion:      3.19
>  Contact:       linux-input@vger.kernel.org
>  Description:
>                 (RW) This parameter controls the period of time to test for a
> -               ‘hands off’ condition (i.e. when no force is applied) before a
> +               'hands off' condition (i.e. when no force is applied) before a
>                 drift (noise) calibration occurs.
>
>                 IBM Trackpoints have a feature to compensate for drift by
> diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc
> index ea999e292f11..7f90c6a44610 100644
> --- a/Documentation/ABI/testing/sysfs-devices-soc
> +++ b/Documentation/ABI/testing/sysfs-devices-soc
> @@ -27,11 +27,11 @@ Description:
>                 (e.g. DB8500).
>
>                 On many of ARM based silicon with SMCCC v1.2+ compliant firmware
> -               this will contain the JEDEC JEP106 manufacturer’s identification
> +               this will contain the JEDEC JEP106 manufacturer's identification
>                 code. The format is "jep106:XXYY" where XX is identity code and
>                 YY is continuation code.
>
> -               This manufacturer’s identification code is defined by one
> +               This manufacturer's identification code is defined by one
>                 or more eight (8) bit fields, each consisting of seven (7)
>                 data bits plus one (1) odd parity bit. It is a single field,
>                 limiting the possible number of vendors to 126. To expand
> --
> 2.30.2
>

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 13:38         ` Mauro Carvalho Chehab
                             ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 13:58           ` Edward Cree
  -1 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with × or — in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ×.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:58           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with × or — in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ×.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:58           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with × or — in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ×.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:58           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with × or — in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ×.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:58           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with × or — in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ×.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:58           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with × or — in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ×.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:58           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 13:58 UTC (permalink / raw)
  To: intel-wired-lan

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote:
> Em Mon, 10 May 2021 14:16:16 +0100
> Edward Cree <ecree.xilinx@gmail.com> escreveu:
>> But what kinds of things with ? or ? in are going to be grept for?
> 
> Actually, on almost all places, those aren't used inside math formulae, but
> instead, they describe video some resolutions:
Ehh, those are also proper uses of ?.  It's still a multiplication,
 after all.

> it is a way more likely that, if someone wants to grep, they would be 
> doing something like this, in order to get video resolutions:
Why would someone be grepping for "all video resolutions mentioned in
 the documentation"?  That seems contrived to me.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 13:16       ` Edward Cree
                           ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 13:59         ` Matthew Wilcox
  -1 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: Edward Cree
  Cc: Mauro Carvalho Chehab, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('—'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:59         ` Matthew Wilcox
  0 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: Edward Cree
  Cc: Mauro Carvalho Chehab, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('—'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:59         ` Matthew Wilcox
  0 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity, David Woodhouse

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('—'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:59         ` Matthew Wilcox
  0 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity, David Woodhouse

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('—'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:59         ` Matthew Wilcox
  0 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: Edward Cree
  Cc: Mauro Carvalho Chehab, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('—'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:59         ` Matthew Wilcox
  0 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity, David Woodhouse

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('—'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because — even in
>  monospace fonts — they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions — like en dashes — are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 13:59         ` Matthew Wilcox
  0 siblings, 0 replies; 219+ messages in thread
From: Matthew Wilcox @ 2021-05-10 13:59 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote:
> On 10/05/2021 12:55, Mauro Carvalho Chehab wrote:
> > The main point on this series is to replace just the occurrences
> > where ASCII represents the symbol equally well
> 
> > 	- U+2014 ('?'): EM DASH
> Em dash is not the same thing as hyphen-minus, and the latter does not
>  serve 'equally well'.  People use em dashes because ? even in
>  monospace fonts ? they make text easier to read and comprehend, when
>  used correctly.
> I accept that some of the other distinctions ? like en dashes ? are
>  needlessly pedantic (though I don't doubt there is someone out there
>  who will gladly defend them with the same fervour with which I argue
>  for the em dash) and I wouldn't take the trouble to use them myself;
>  but I think there is a reasonable assumption that when someone goes
>  to the effort of using a Unicode punctuation mark that is semantic
>  (rather than merely typographical), they probably had a reason for
>  doing so.

I think you're overestimating the amount of care and typographical
knowledge that your average kernel developer has.  Most of these
UTF-8 characters come from latex conversions and really aren't
necessary (and are being used incorrectly).

You seem quite knowedgeable about the various differences.  Perhaps
you'd be willing to write a document for Documentation/doc-guide/
that provides guidance for when to use which kinds of horizontal
line?  https://www.punctuationmatters.com/hyphen-dash-n-dash-and-m-dash/
talks about it in the context of publications, but I think we need
something more suited to our needs for kernel documentation.

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 11:55     ` Mauro Carvalho Chehab
                         ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 14:00       ` Ben Boeckel
  -1 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:00       ` Ben Boeckel
  0 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:00       ` Ben Boeckel
  0 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:00       ` Ben Boeckel
  0 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:00       ` Ben Boeckel
  0 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:00       ` Ben Boeckel
  0 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:00       ` Ben Boeckel
  0 siblings, 0 replies; 219+ messages in thread
From: Ben Boeckel @ 2021-05-10 14:00 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, May 10, 2021 at 13:55:18 +0200, Mauro Carvalho Chehab wrote:
>     $ git grep "CPU 0 has been" Documentation/RCU/
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>       Documentation/RCU/Design/Data-Structures/Data-Structures.rst:|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |

The kernel documentation uses hard line wraps, so such a naive grep is
going to always fail unless such line wraps are taken into account. Not
saying this isn't an improvement in and of itself, but smarter searching
strategies are likely needed anyways.

--Ben

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 13:59         ` Matthew Wilcox
                             ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 14:33           ` Edward Cree
  -1 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Mauro Carvalho Chehab, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:33           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Mauro Carvalho Chehab, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:33           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity, David Woodhouse

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:33           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity, David Woodhouse

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:33           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Mauro Carvalho Chehab, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:33           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity, David Woodhouse

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 14:33           ` Edward Cree
  0 siblings, 0 replies; 219+ messages in thread
From: Edward Cree @ 2021-05-10 14:33 UTC (permalink / raw)
  To: intel-wired-lan

On 10/05/2021 14:59, Matthew Wilcox wrote:
> Most of these
> UTF-8 characters come from latex conversions and really aren't
> necessary (and are being used incorrectly).
I fully agree with fixing those.
The cover-letter, however, gave the impression that that was not the
 main purpose of this series; just, perhaps, a happy side-effect.

> You seem quite knowedgeable about the various differences.  Perhaps
> you'd be willing to write a document for Documentation/doc-guide/
> that provides guidance for when to use which kinds of horizontal
> line?I have Opinions about the proper usage of punctuation, but I also know
 that other people have differing opinions.  For instance, I place
 spaces around an em dash, which is nonstandard according to most
 style guides.  Really this is an individual enough thing that I'm not
 sure we could have a "kernel style guide" that would be more useful
 than general-purpose guidance like the page you linked.
Moreover, such a guide could make non-native speakers needlessly self-
 conscious about their writing and discourage them from contributing
 documentation at all.  I'm not advocating here for trying to push
 kernel developers towards an eats-shoots-and-leaves level of
 linguistic pedantry; rather, I merely think that existing correct
 usages should be left intact (and therefore, excising incorrect usage
 should only be attempted by someone with both the expertise and time
 to check each case).

But if you really want such a doc I wouldn't mind contributing to it.

-ed

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 13/53] docs: driver-api: fpga: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 13/53] docs: driver-api: fpga: " Mauro Carvalho Chehab
@ 2021-05-10 17:48   ` Moritz Fischer
  0 siblings, 0 replies; 219+ messages in thread
From: Moritz Fischer @ 2021-05-10 17:48 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Moritz Fischer, Tom Rix,
	linux-fpga, linux-kernel

On Mon, May 10, 2021 at 12:26:25PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2014 ('—'): EM DASH
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/driver-api/fpga/fpga-bridge.rst | 10 +++++-----
>  Documentation/driver-api/fpga/fpga-mgr.rst    | 12 +++++------
>  .../driver-api/fpga/fpga-programming.rst      |  8 ++++----
>  Documentation/driver-api/fpga/fpga-region.rst | 20 +++++++++----------
>  4 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
> index 198aadafd3e7..8d650b4e2ce6 100644
> --- a/Documentation/driver-api/fpga/fpga-bridge.rst
> +++ b/Documentation/driver-api/fpga/fpga-bridge.rst
> @@ -4,11 +4,11 @@ FPGA Bridge
>  API to implement a new FPGA bridge
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> -* struct fpga_bridge — The FPGA Bridge structure
> -* struct fpga_bridge_ops — Low level Bridge driver ops
> -* devm_fpga_bridge_create() — Allocate and init a bridge struct
> -* fpga_bridge_register() — Register a bridge
> -* fpga_bridge_unregister() — Unregister a bridge
> +* struct fpga_bridge - The FPGA Bridge structure
> +* struct fpga_bridge_ops - Low level Bridge driver ops
> +* devm_fpga_bridge_create() - Allocate and init a bridge struct
> +* fpga_bridge_register() - Register a bridge
> +* fpga_bridge_unregister() - Unregister a bridge
>  
>  .. kernel-doc:: include/linux/fpga/fpga-bridge.h
>     :functions: fpga_bridge
> diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
> index 917ee22db429..4d926b452cb3 100644
> --- a/Documentation/driver-api/fpga/fpga-mgr.rst
> +++ b/Documentation/driver-api/fpga/fpga-mgr.rst
> @@ -101,12 +101,12 @@ in state.
>  API for implementing a new FPGA Manager driver
>  ----------------------------------------------
>  
> -* ``fpga_mgr_states`` —  Values for :c:expr:`fpga_manager->state`.
> -* struct fpga_manager —  the FPGA manager struct
> -* struct fpga_manager_ops —  Low level FPGA manager driver ops
> -* devm_fpga_mgr_create() —  Allocate and init a manager struct
> -* fpga_mgr_register() —  Register an FPGA manager
> -* fpga_mgr_unregister() —  Unregister an FPGA manager
> +* ``fpga_mgr_states`` -  Values for :c:expr:`fpga_manager->state`.
> +* struct fpga_manager -  the FPGA manager struct
> +* struct fpga_manager_ops -  Low level FPGA manager driver ops
> +* devm_fpga_mgr_create() -  Allocate and init a manager struct
> +* fpga_mgr_register() -  Register an FPGA manager
> +* fpga_mgr_unregister() -  Unregister an FPGA manager
>  
>  .. kernel-doc:: include/linux/fpga/fpga-mgr.h
>     :functions: fpga_mgr_states
> diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst
> index 002392dab04f..fb4da4240e96 100644
> --- a/Documentation/driver-api/fpga/fpga-programming.rst
> +++ b/Documentation/driver-api/fpga/fpga-programming.rst
> @@ -84,10 +84,10 @@ will generate that list.  Here's some sample code of what to do next::
>  API for programming an FPGA
>  ---------------------------
>  
> -* fpga_region_program_fpga() —  Program an FPGA
> -* fpga_image_info() —  Specifies what FPGA image to program
> -* fpga_image_info_alloc() —  Allocate an FPGA image info struct
> -* fpga_image_info_free() —  Free an FPGA image info struct
> +* fpga_region_program_fpga() -  Program an FPGA
> +* fpga_image_info() -  Specifies what FPGA image to program
> +* fpga_image_info_alloc() -  Allocate an FPGA image info struct
> +* fpga_image_info_free() -  Free an FPGA image info struct
>  
>  .. kernel-doc:: drivers/fpga/fpga-region.c
>     :functions: fpga_region_program_fpga
> diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
> index 363a8171ab0a..2636a27c11b2 100644
> --- a/Documentation/driver-api/fpga/fpga-region.rst
> +++ b/Documentation/driver-api/fpga/fpga-region.rst
> @@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_.
>  API to add a new FPGA region
>  ----------------------------
>  
> -* struct fpga_region — The FPGA region struct
> -* devm_fpga_region_create() — Allocate and init a region struct
> -* fpga_region_register() —  Register an FPGA region
> -* fpga_region_unregister() —  Unregister an FPGA region
> +* struct fpga_region - The FPGA region struct
> +* devm_fpga_region_create() - Allocate and init a region struct
> +* fpga_region_register() -  Register an FPGA region
> +* fpga_region_unregister() -  Unregister an FPGA region
>  
>  The FPGA region's probe function will need to get a reference to the FPGA
>  Manager it will be using to do the programming.  This usually would happen
>  during the region's probe function.
>  
> -* fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count
> -* of_fpga_mgr_get() —  Get a reference to an FPGA manager, raise ref count,
> +* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count
> +* of_fpga_mgr_get() -  Get a reference to an FPGA manager, raise ref count,
>    given a device node.
> -* fpga_mgr_put() — Put an FPGA manager
> +* fpga_mgr_put() - Put an FPGA manager
>  
>  The FPGA region will need to specify which bridges to control while programming
>  the FPGA.  The region driver can build a list of bridges during probe time
> @@ -66,11 +66,11 @@ the list of bridges to program just before programming
>  (:c:expr:`fpga_region->get_bridges`).  The FPGA bridge framework supplies the
>  following APIs to handle building or tearing down that list.
>  
> -* fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
> +* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
>    list
> -* of_fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
> +* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a
>    list, given a device node
> -* fpga_bridges_put() — Given a list of bridges, put them
> +* fpga_bridges_put() - Given a list of bridges, put them
>  
>  .. kernel-doc:: include/linux/fpga/fpga-region.h
>     :functions: fpga_region
> -- 
> 2.30.2
> 

Applied to for-next,

Thanks

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 06/53] docs: admin-guide: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 06/53] docs: admin-guide: " Mauro Carvalho Chehab
@ 2021-05-10 18:40   ` Gabriel Krisman Bertazi
  2021-05-12  8:44     ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 219+ messages in thread
From: Gabriel Krisman Bertazi @ 2021-05-10 18:40 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Daniel W. S. Almeida, Jonathan Corbet,
	Arnd Bergmann, Borislav Petkov, David Howells, David Woodhouse,
	Greg Kroah-Hartman, James Morse, Kees Cook,
	Mauro Carvalho Chehab, Robert Richter, Thorsten Leemhuis,
	Tony Luck, keyrings, linux-edac, linux-kernel

Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:

> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
> 	- U+00a0 (' '): NO-BREAK SPACE
> 	- U+2013 ('–'): EN DASH
> 	- U+2014 ('—'): EM DASH
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  Documentation/admin-guide/index.rst           |  2 +-
>  Documentation/admin-guide/module-signing.rst  |  4 +-
>  Documentation/admin-guide/ras.rst             | 94 +++++++++----------
>  .../admin-guide/reporting-issues.rst          | 12 +--
>  4 files changed, 56 insertions(+), 56 deletions(-)

Hi Mauro,

This patch misses one occurrence of U+2014 in
Documentation/admin-guide/sysctl/kernel.rst:1288.

There are also countless occurrences in Documentation/, outside of
Documentation/admin-guide.  I suppose another patch in the series, which
I didn't receive, will fix them?

These characters will just reappear elsewhere, eventually. I'm not sure
what is the gain here, other than minor consistence improvements. But we
should add a Warning during documentation generation (if there isn't one
already), to prevent them from spreading again.

-- 
Gabriel Krisman Bertazi

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 13:49       ` David Woodhouse
                           ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 19:22         ` Theodore Ts'o
  -1 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Mauro Carvalho Chehab, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 19:22         ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Mauro Carvalho Chehab, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 19:22         ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 19:22         ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 19:22         ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Mauro Carvalho Chehab, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 19:22         ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	Mauro Carvalho Chehab, x86, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-rdma, linux-integrity

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 19:22         ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:22 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].
> 
> Replacing those makes sense. But replacing emdashes ? which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus ? does not.

I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
hypens into my text editor of choice than trying to enter the UTF-8
characters.  If we can make sphinx do this translation, maybe that's
the best way of dealing with these two characters?

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 28/53] docs: filesystems: ext4: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 28/53] docs: filesystems: ext4: " Mauro Carvalho Chehab
@ 2021-05-10 19:23   ` Theodore Ts'o
  0 siblings, 0 replies; 219+ messages in thread
From: Theodore Ts'o @ 2021-05-10 19:23 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Andreas Dilger,
	linux-ext4, linux-kernel

On Mon, May 10, 2021 at 12:26:40PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
> 	- U+2217 ('∗'): ASTERISK OPERATOR
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Acked-by: Theodore Ts'o <tytso@mit.edu>

Thanks,

					- Ted

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: avoid using UTF-8 chars
  2021-05-10 10:26   ` Mauro Carvalho Chehab
@ 2021-05-10 19:28     ` Mathieu Poirier
  -1 siblings, 0 replies; 219+ messages in thread
From: Mathieu Poirier @ 2021-05-10 19:28 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Leo Yan, Mike Leach,
	Suzuki K Poulose, coresight, linux-arm-kernel, linux-kernel

On Mon, May 10, 2021 at 12:26:23PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+00a0 (' '): NO-BREAK SPACE
> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

> ---
>  .../coresight/coresight-etm4x-reference.rst      | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
> index b64d9a9c79df..e8ddfc144d9a 100644
> --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
> +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
> @@ -15,14 +15,14 @@ Root: ``/sys/bus/coresight/devices/etm<N>``
>  
>  The following paragraphs explain the association between sysfs files and the
>  ETMv4 registers that they effect. Note the register names are given without
> -the ‘TRC’ prefix.
> +the 'TRC' prefix.
>  
>  ----
>  
>  :File:            ``mode`` (rw)
>  :Trace Registers: {CONFIGR + others}
>  :Notes:
> -    Bit select trace features. See ‘mode’ section below. Bits
> +    Bit select trace features. See 'mode' section below. Bits
>      in this will cause equivalent programming of trace config and
>      other registers to enable the features requested.
>  
> @@ -89,7 +89,7 @@ the ‘TRC’ prefix.
>  :Notes:
>      Pair of addresses for a range selected by addr_idx. Include
>      / exclude according to the optional parameter, or if omitted
> -    uses the current ‘mode’ setting. Select comparator range in
> +    uses the current 'mode' setting. Select comparator range in
>      control register. Error if index is odd value.
>  
>  :Depends: ``mode, addr_idx``
> @@ -277,7 +277,7 @@ the ‘TRC’ prefix.
>  :Trace Registers: VICTLR{23:20}
>  :Notes:
>      Program non-secure exception level filters. Set / clear NS
> -    exception filter bits. Setting ‘1’ excludes trace from the
> +    exception filter bits. Setting '1' excludes trace from the
>      exception level.
>  
>  :Syntax:
> @@ -427,7 +427,7 @@ the ‘TRC’ prefix.
>  :Syntax:
>      ``echo idx > vmid_idx``
>  
> -    Where idx <  numvmidc
> +    Where idx <  numvmidc
>  
>  ----
>  
> @@ -628,7 +628,7 @@ the reset parameter::
>  
>  
>  
> -The ‘mode’ sysfs parameter.
> +The 'mode' sysfs parameter.
>  ---------------------------
>  
>  This is a bitfield selection parameter that sets the overall trace mode for the
> @@ -696,7 +696,7 @@ Bit assignments shown below:-
>      ETM_MODE_QELEM(val)
>  
>  **description:**
> -    ‘val’ determines level of Q element support enabled if
> +    'val' determines level of Q element support enabled if
>      implemented by the ETM [IDR0]
>  
>  
> @@ -780,7 +780,7 @@ Bit assignments shown below:-
>  ----
>  
>  *Note a)* On startup the ETM is programmed to trace the complete address space
> -using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
> +using address range comparator 0. 'mode' bits 30 / 31 modify this setting to
>  set EL exclude bits for NS state in either user space (EL0) or kernel space
>  (EL1) in the address range comparator. (the default setting excludes all
>  secure EL, and NS EL2)
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: avoid using UTF-8 chars
@ 2021-05-10 19:28     ` Mathieu Poirier
  0 siblings, 0 replies; 219+ messages in thread
From: Mathieu Poirier @ 2021-05-10 19:28 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Leo Yan, Mike Leach,
	Suzuki K Poulose, coresight, linux-arm-kernel, linux-kernel

On Mon, May 10, 2021 at 12:26:23PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+00a0 (' '): NO-BREAK SPACE
> 	- U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
> 	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

> ---
>  .../coresight/coresight-etm4x-reference.rst      | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
> index b64d9a9c79df..e8ddfc144d9a 100644
> --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
> +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
> @@ -15,14 +15,14 @@ Root: ``/sys/bus/coresight/devices/etm<N>``
>  
>  The following paragraphs explain the association between sysfs files and the
>  ETMv4 registers that they effect. Note the register names are given without
> -the ‘TRC’ prefix.
> +the 'TRC' prefix.
>  
>  ----
>  
>  :File:            ``mode`` (rw)
>  :Trace Registers: {CONFIGR + others}
>  :Notes:
> -    Bit select trace features. See ‘mode’ section below. Bits
> +    Bit select trace features. See 'mode' section below. Bits
>      in this will cause equivalent programming of trace config and
>      other registers to enable the features requested.
>  
> @@ -89,7 +89,7 @@ the ‘TRC’ prefix.
>  :Notes:
>      Pair of addresses for a range selected by addr_idx. Include
>      / exclude according to the optional parameter, or if omitted
> -    uses the current ‘mode’ setting. Select comparator range in
> +    uses the current 'mode' setting. Select comparator range in
>      control register. Error if index is odd value.
>  
>  :Depends: ``mode, addr_idx``
> @@ -277,7 +277,7 @@ the ‘TRC’ prefix.
>  :Trace Registers: VICTLR{23:20}
>  :Notes:
>      Program non-secure exception level filters. Set / clear NS
> -    exception filter bits. Setting ‘1’ excludes trace from the
> +    exception filter bits. Setting '1' excludes trace from the
>      exception level.
>  
>  :Syntax:
> @@ -427,7 +427,7 @@ the ‘TRC’ prefix.
>  :Syntax:
>      ``echo idx > vmid_idx``
>  
> -    Where idx <  numvmidc
> +    Where idx <  numvmidc
>  
>  ----
>  
> @@ -628,7 +628,7 @@ the reset parameter::
>  
>  
>  
> -The ‘mode’ sysfs parameter.
> +The 'mode' sysfs parameter.
>  ---------------------------
>  
>  This is a bitfield selection parameter that sets the overall trace mode for the
> @@ -696,7 +696,7 @@ Bit assignments shown below:-
>      ETM_MODE_QELEM(val)
>  
>  **description:**
> -    ‘val’ determines level of Q element support enabled if
> +    'val' determines level of Q element support enabled if
>      implemented by the ETM [IDR0]
>  
>  
> @@ -780,7 +780,7 @@ Bit assignments shown below:-
>  ----
>  
>  *Note a)* On startup the ETM is programmed to trace the complete address space
> -using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
> +using address range comparator 0. 'mode' bits 30 / 31 modify this setting to
>  set EL exclude bits for NS state in either user space (EL0) or kernel space
>  (EL1) in the address range comparator. (the default setting excludes all
>  secure EL, and NS EL2)
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 10:26 ` Mauro Carvalho Chehab
                     ` (4 preceding siblings ...)
  (?)
@ 2021-05-10 21:57   ` Adam Borowski
  -1 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 • Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 • some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

⬍ is not found in any of the above.  You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 21:57   ` Adam Borowski
  0 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 • Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 • some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

⬍ is not found in any of the above.  You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 21:57   ` Adam Borowski
  0 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 • Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 • some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

⬍ is not found in any of the above.  You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 21:57   ` Adam Borowski
  0 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 • Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 • some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

⬍ is not found in any of the above.  You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 21:57   ` Adam Borowski
  0 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 • Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 • some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

⬍ is not found in any of the above.  You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 21:57   ` Adam Borowski
  0 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 • Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 • some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('⬍'): UP DOWN BLACK ARROW

× is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

⬍ is not found in any of the above.  You might want to at least
convert it to ↕ which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄⠀⠀⠀⠀ `----
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-10 21:57   ` Adam Borowski
  0 siblings, 0 replies; 219+ messages in thread
From: Adam Borowski @ 2021-05-10 21:57 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, May 10, 2021 at 12:26:12PM +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
[...]
> Other UTF-8 characters were added along the time, but they're easily
> replaceable by ASCII chars.
> 
> As Linux developers are all around the globe, and not everybody has UTF-8
> as their default charset

I'm not aware of a distribution that still allows selecting a non-UTF-8
charset in a normal flow in their installer.  And if they haven't purged
support for ancient encodings, that support is thoroughly bitrotten.
Thus, I disagree that this is a legitimate concern.

What _could_ be a legitimate reason is that someone is on a _terminal_
that can't display a wide enough set of glyphs.  Such terminals are:
 ? Linux console (because of vgacon limitations; patchsets to improve
   other cons haven't been mainlined)
 ? some Windows terminals (putty, old Windows console) that can't borrow
   glyphs from other fonts like fontconfig can

For the former, it's whatever your distribution ships in
/usr/share/consolefonts/ or an equivalent, which is based on historic
ISO-8859 and VT100 traditions.

For the latter, the near-guaranteed character set is WGL4.


Thus, at least two of your choices seem to disagree with the above:
[dropped]
> 	0xd7   => 'x',		# MULTIPLICATION SIGN
[retained]
> 	- U+2b0d ('?'): UP DOWN BLACK ARROW

? is present in ISO-8859, V100, WGL4; I've found no font in
/usr/share/consolefonts/ on my Debian unstable box that lacks this
character.

? is not found in any of the above.  You might want to at least
convert it to ? which is at least present in WGL4, and thus likely
to be supported in fonts heeding Windows/Mac/OpenType recommendations.
That still won't make it work on VT.


Meow!
-- 
??????? .--[ Makefile ]
??????? # beware of races
??????? all: pillage burn
??????? `----

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 39/53] docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  2021-05-10 10:26 ` [PATCH 39/53] docs: dev-tools: testing-overview.rst: " Mauro Carvalho Chehab
  2021-05-10 10:48   ` Marco Elver
@ 2021-05-10 23:35   ` David Gow
  2021-05-12  8:14     ` Mauro Carvalho Chehab
  2021-05-12  8:29     ` Mauro Carvalho Chehab
  1 sibling, 2 replies; 219+ messages in thread
From: David Gow @ 2021-05-10 23:35 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet, Daniel Latypov,
	Marco Elver, Linux Kernel Mailing List

On Mon, May 10, 2021 at 6:27 PM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
>
>         - U+2014 ('—'): EM DASH
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---

Oh dear, I do have a habit of overusing em-dashes. I've no problem in
theory with exchanging them for an ASCII approximation.
I suppose there's a reason it's the one dash to rule them all: :-)
https://twitter.com/FakeUnicode/status/727888721312260096/photo/1

>  Documentation/dev-tools/testing-overview.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
> index b5b46709969c..8adffc26a2ec 100644
> --- a/Documentation/dev-tools/testing-overview.rst
> +++ b/Documentation/dev-tools/testing-overview.rst
> @@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
>  groups of tests easier, as well as providing helpers to aid in writing new
>  tests.
>
> -If you're looking to verify the behaviour of the Kernel — particularly specific
> -parts of the kernel — then you'll want to use KUnit or kselftest.
> +If you're looking to verify the behaviour of the Kernel - particularly specific
> +parts of the kernel - then you'll want to use KUnit or kselftest.

As Marco pointed out, having multiple HYPHEN-MINUS symbols in a row is
probably a better replacement, as it does distinguish the em-dash from
smaller dashes better.
However, I need three for sphinx to output an em-dash here (2 hyphens
only gives me an en-dash).

So, if we want to get rid of the UTF-8 em-dash, my preferences would
be (in descending order):
1. Three hyphens: '---' (sphinx generates an em-dash)
2. Two hyphens: '--' (worst case, an en-dash surrounded by spaces --
as sphinx generates for me -- is still readable, and it's still
readable as an em-dash in plain text)
3. One hyphen as in this patch (which I don't like as much, but will
no doubt learn to live with)

But it looks like you've got several similar comments on other patches
in this series, so I'm happy for you to use whatever ends up being
agreed upon generally.

Cheers,
-- David

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 53/53] docs: RCU: avoid using UTF-8 chars
  2021-05-10 10:27 ` [PATCH 53/53] docs: RCU: " Mauro Carvalho Chehab
@ 2021-05-11  0:05   ` Paul E. McKenney
  0 siblings, 0 replies; 219+ messages in thread
From: Paul E. McKenney @ 2021-05-11  0:05 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Linux Doc Mailing List, Jonathan Corbet,
	Nícolas F. R. A. Prado, Joel Fernandes, Josh Triplett,
	Lai Jiangshan, Mathieu Desnoyers, Randy Dunlap,
	Sebastian Andrzej Siewior, Steven Rostedt, Takashi Iwai,
	linux-kernel, rcu

On Mon, May 10, 2021 at 12:27:05PM +0200, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+00a0 (' '): NO-BREAK SPACE
> 	- U+2013 ('–'): EN DASH
> 	- U+2014 ('—'): EM DASH
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Acked-by: Paul E. McKenney <paulmck@kernel.org>

> ---
>  .../Data-Structures/Data-Structures.rst       |  52 ++++----
>  .../Expedited-Grace-Periods.rst               |  40 +++---
>  .../Tree-RCU-Memory-Ordering.rst              |  10 +-
>  .../RCU/Design/Requirements/Requirements.rst  | 126 +++++++++---------
>  4 files changed, 114 insertions(+), 114 deletions(-)
> 
> diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
> index f4efd6897b09..e95c6c8eeb6a 100644
> --- a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
> +++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
> @@ -301,7 +301,7 @@ The ``->gp_max`` field tracks the duration of the longest grace period
>  in jiffies. It is protected by the root ``rcu_node``'s ``->lock``.
>  
>  The ``->name`` and ``->abbr`` fields distinguish between preemptible RCU
> -(“rcu_preempt” and “p”) and non-preemptible RCU (“rcu_sched” and “s”).
> +("rcu_preempt" and "p") and non-preemptible RCU ("rcu_sched" and "s").
>  These fields are used for diagnostic and tracing purposes.
>  
>  The ``rcu_node`` Structure
> @@ -456,21 +456,21 @@ expedited grace periods, respectively.
>  | Lockless grace-period computation! Such a tantalizing possibility!    |
>  | But consider the following sequence of events:                        |
>  |                                                                       |
> -| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
> +| #. CPU 0 has been in dyntick-idle mode for quite some time. When it   |
>  |    wakes up, it notices that the current RCU grace period needs it to |
>  |    report in, so it sets a flag where the scheduling clock interrupt  |
>  |    will find it.                                                      |
> -| #. Meanwhile, CPU 1 is running ``force_quiescent_state()``, and       |
> -|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |
> +| #. Meanwhile, CPU 1 is running ``force_quiescent_state()``, and       |
> +|    notices that CPU 0 has been in dyntick idle mode, which qualifies  |
>  |    as an extended quiescent state.                                    |
> -| #. CPU 0's scheduling clock interrupt fires in the middle of an RCU   |
> +| #. CPU 0's scheduling clock interrupt fires in the middle of an RCU   |
>  |    read-side critical section, and notices that the RCU core needs    |
>  |    something, so commences RCU softirq processing.                    |
> -| #. CPU 0's softirq handler executes and is just about ready to report |
> +| #. CPU 0's softirq handler executes and is just about ready to report |
>  |    its quiescent state up the ``rcu_node`` tree.                      |
> -| #. But CPU 1 beats it to the punch, completing the current grace      |
> +| #. But CPU 1 beats it to the punch, completing the current grace      |
>  |    period and starting a new one.                                     |
> -| #. CPU 0 now reports its quiescent state for the wrong grace period.  |
> +| #. CPU 0 now reports its quiescent state for the wrong grace period.  |
>  |    That grace period might now end before the RCU read-side critical  |
>  |    section. If that happens, disaster will ensue.                     |
>  |                                                                       |
> @@ -515,18 +515,18 @@ removes itself from the ``->blkd_tasks`` list, then that task must
>  advance the pointer to the next task on the list, or set the pointer to
>  ``NULL`` if there are no subsequent tasks on the list.
>  
> -For example, suppose that tasks T1, T2, and T3 are all hard-affinitied
> -to the largest-numbered CPU in the system. Then if task T1 blocked in an
> +For example, suppose that tasks T1, T2, and T3 are all hard-affinitied
> +to the largest-numbered CPU in the system. Then if task T1 blocked in an
>  RCU read-side critical section, then an expedited grace period started,
> -then task T2 blocked in an RCU read-side critical section, then a normal
> -grace period started, and finally task 3 blocked in an RCU read-side
> +then task T2 blocked in an RCU read-side critical section, then a normal
> +grace period started, and finally task 3 blocked in an RCU read-side
>  critical section, then the state of the last leaf ``rcu_node``
>  structure's blocked-task list would be as shown below:
>  
>  .. kernel-figure:: blkd_task.svg
>  
> -Task T1 is blocking both grace periods, task T2 is blocking only the
> -normal grace period, and task T3 is blocking neither grace period. Note
> +Task T1 is blocking both grace periods, task T2 is blocking only the
> +normal grace period, and task T3 is blocking neither grace period. Note
>  that these tasks will not remove themselves from this list immediately
>  upon resuming execution. They will instead remain on the list until they
>  execute the outermost ``rcu_read_unlock()`` that ends their RCU
> @@ -611,8 +611,8 @@ expressions as follows:
>     66 #endif
>  
>  The maximum number of levels in the ``rcu_node`` structure is currently
> -limited to four, as specified by lines 21-24 and the structure of the
> -subsequent “if” statement. For 32-bit systems, this allows
> +limited to four, as specified by lines 21-24 and the structure of the
> +subsequent "if" statement. For 32-bit systems, this allows
>  16*32*32*32=524,288 CPUs, which should be sufficient for the next few
>  years at least. For 64-bit systems, 16*64*64*64=4,194,304 CPUs is
>  allowed, which should see us through the next decade or so. This
> @@ -638,9 +638,9 @@ fields. The number of CPUs per leaf ``rcu_node`` structure is therefore
>  limited to 16 given the default value of ``CONFIG_RCU_FANOUT_LEAF``. If
>  ``CONFIG_RCU_FANOUT_LEAF`` is unspecified, the value selected is based
>  on the word size of the system, just as for ``CONFIG_RCU_FANOUT``.
> -Lines 11-19 perform this computation.
> +Lines 11-19 perform this computation.
>  
> -Lines 21-24 compute the maximum number of CPUs supported by a
> +Lines 21-24 compute the maximum number of CPUs supported by a
>  single-level (which contains a single ``rcu_node`` structure),
>  two-level, three-level, and four-level ``rcu_node`` tree, respectively,
>  given the fanout specified by ``RCU_FANOUT`` and ``RCU_FANOUT_LEAF``.
> @@ -649,18 +649,18 @@ These numbers of CPUs are retained in the ``RCU_FANOUT_1``,
>  variables, respectively.
>  
>  These variables are used to control the C-preprocessor ``#if`` statement
> -spanning lines 26-66 that computes the number of ``rcu_node`` structures
> +spanning lines 26-66 that computes the number of ``rcu_node`` structures
>  required for each level of the tree, as well as the number of levels
>  required. The number of levels is placed in the ``NUM_RCU_LVLS``
> -C-preprocessor variable by lines 27, 35, 44, and 54. The number of
> +C-preprocessor variable by lines 27, 35, 44, and 54. The number of
>  ``rcu_node`` structures for the topmost level of the tree is always
>  exactly one, and this value is unconditionally placed into
> -``NUM_RCU_LVL_0`` by lines 28, 36, 45, and 55. The rest of the levels
> +``NUM_RCU_LVL_0`` by lines 28, 36, 45, and 55. The rest of the levels
>  (if any) of the ``rcu_node`` tree are computed by dividing the maximum
>  number of CPUs by the fanout supported by the number of levels from the
>  current level down, rounding up. This computation is performed by
> -lines 37, 46-47, and 56-58. Lines 31-33, 40-42, 50-52, and 62-63 create
> -initializers for lockdep lock-class names. Finally, lines 64-66 produce
> +lines 37, 46-47, and 56-58. Lines 31-33, 40-42, 50-52, and 62-63 create
> +initializers for lockdep lock-class names. Finally, lines 64-66 produce
>  an error if the maximum number of CPUs is too large for the specified
>  fanout.
>  
> @@ -716,13 +716,13 @@ In this figure, the ``->head`` pointer references the first RCU callback
>  in the list. The ``->tails[RCU_DONE_TAIL]`` array element references the
>  ``->head`` pointer itself, indicating that none of the callbacks is
>  ready to invoke. The ``->tails[RCU_WAIT_TAIL]`` array element references
> -callback CB 2's ``->next`` pointer, which indicates that CB 1 and CB 2
> +callback CB 2's ``->next`` pointer, which indicates that CB 1 and CB 2
>  are both waiting on the current grace period, give or take possible
>  disagreements about exactly which grace period is the current one. The
>  ``->tails[RCU_NEXT_READY_TAIL]`` array element references the same RCU
>  callback that ``->tails[RCU_WAIT_TAIL]`` does, which indicates that
>  there are no callbacks waiting on the next RCU grace period. The
> -``->tails[RCU_NEXT_TAIL]`` array element references CB 4's ``->next``
> +``->tails[RCU_NEXT_TAIL]`` array element references CB 4's ``->next``
>  pointer, indicating that all the remaining RCU callbacks have not yet
>  been assigned to an RCU grace period. Note that the
>  ``->tails[RCU_NEXT_TAIL]`` array element always references the last RCU
> @@ -1031,7 +1031,7 @@ field to record the offset of the ``rcu_head`` structure within the
>  enclosing RCU-protected data structure.
>  
>  Both of these fields are used internally by RCU. From the viewpoint of
> -RCU users, this structure is an opaque “cookie”.
> +RCU users, this structure is an opaque "cookie".
>  
>  +-----------------------------------------------------------------------+
>  | **Quick Quiz**:                                                       |
> diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
> index 6f89cf1e567d..742921a7532b 100644
> --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
> +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
> @@ -304,8 +304,8 @@ representing the elements of the ``->exp_wq[]`` array.
>  
>  .. kernel-figure:: Funnel0.svg
>  
> -The next diagram shows the situation after the arrival of Task A and
> -Task B at the leftmost and rightmost leaf ``rcu_node`` structures,
> +The next diagram shows the situation after the arrival of Task A and
> +Task B at the leftmost and rightmost leaf ``rcu_node`` structures,
>  respectively. The current value of the ``rcu_state`` structure's
>  ``->expedited_sequence`` field is zero, so adding three and clearing the
>  bottom bit results in the value two, which both tasks record in the
> @@ -313,13 +313,13 @@ bottom bit results in the value two, which both tasks record in the
>  
>  .. kernel-figure:: Funnel1.svg
>  
> -Each of Tasks A and B will move up to the root ``rcu_node`` structure.
> -Suppose that Task A wins, recording its desired grace-period sequence
> +Each of Tasks A and B will move up to the root ``rcu_node`` structure.
> +Suppose that Task A wins, recording its desired grace-period sequence
>  number and resulting in the state shown below:
>  
>  .. kernel-figure:: Funnel2.svg
>  
> -Task A now advances to initiate a new grace period, while Task B moves
> +Task A now advances to initiate a new grace period, while Task B moves
>  up to the root ``rcu_node`` structure, and, seeing that its desired
>  sequence number is already recorded, blocks on ``->exp_wq[1]``.
>  
> @@ -340,7 +340,7 @@ sequence number is already recorded, blocks on ``->exp_wq[1]``.
>  | ``->exp_wq[1]``.                                                      |
>  +-----------------------------------------------------------------------+
>  
> -If Tasks C and D also arrive at this point, they will compute the same
> +If Tasks C and D also arrive at this point, they will compute the same
>  desired grace-period sequence number, and see that both leaf
>  ``rcu_node`` structures already have that value recorded. They will
>  therefore block on their respective ``rcu_node`` structures'
> @@ -348,52 +348,52 @@ therefore block on their respective ``rcu_node`` structures'
>  
>  .. kernel-figure:: Funnel3.svg
>  
> -Task A now acquires the ``rcu_state`` structure's ``->exp_mutex`` and
> +Task A now acquires the ``rcu_state`` structure's ``->exp_mutex`` and
>  initiates the grace period, which increments ``->expedited_sequence``.
> -Therefore, if Tasks E and F arrive, they will compute a desired sequence
> +Therefore, if Tasks E and F arrive, they will compute a desired sequence
>  number of 4 and will record this value as shown below:
>  
>  .. kernel-figure:: Funnel4.svg
>  
> -Tasks E and F will propagate up the ``rcu_node`` combining tree, with
> -Task F blocking on the root ``rcu_node`` structure and Task E wait for
> -Task A to finish so that it can start the next grace period. The
> +Tasks E and F will propagate up the ``rcu_node`` combining tree, with
> +Task F blocking on the root ``rcu_node`` structure and Task E wait for
> +Task A to finish so that it can start the next grace period. The
>  resulting state is as shown below:
>  
>  .. kernel-figure:: Funnel5.svg
>  
> -Once the grace period completes, Task A starts waking up the tasks
> +Once the grace period completes, Task A starts waking up the tasks
>  waiting for this grace period to complete, increments the
>  ``->expedited_sequence``, acquires the ``->exp_wake_mutex`` and then
>  releases the ``->exp_mutex``. This results in the following state:
>  
>  .. kernel-figure:: Funnel6.svg
>  
> -Task E can then acquire ``->exp_mutex`` and increment
> -``->expedited_sequence`` to the value three. If new tasks G and H arrive
> +Task E can then acquire ``->exp_mutex`` and increment
> +``->expedited_sequence`` to the value three. If new tasks G and H arrive
>  and moves up the combining tree at the same time, the state will be as
>  follows:
>  
>  .. kernel-figure:: Funnel7.svg
>  
>  Note that three of the root ``rcu_node`` structure's waitqueues are now
> -occupied. However, at some point, Task A will wake up the tasks blocked
> +occupied. However, at some point, Task A will wake up the tasks blocked
>  on the ``->exp_wq`` waitqueues, resulting in the following state:
>  
>  .. kernel-figure:: Funnel8.svg
>  
> -Execution will continue with Tasks E and H completing their grace
> +Execution will continue with Tasks E and H completing their grace
>  periods and carrying out their wakeups.
>  
>  +-----------------------------------------------------------------------+
>  | **Quick Quiz**:                                                       |
>  +-----------------------------------------------------------------------+
> -| What happens if Task A takes so long to do its wakeups that Task E's  |
> +| What happens if Task A takes so long to do its wakeups that Task E's  |
>  | grace period completes?                                               |
>  +-----------------------------------------------------------------------+
>  | **Answer**:                                                           |
>  +-----------------------------------------------------------------------+
> -| Then Task E will block on the ``->exp_wake_mutex``, which will also   |
> +| Then Task E will block on the ``->exp_wake_mutex``, which will also   |
>  | prevent it from releasing ``->exp_mutex``, which in turn will prevent |
>  | the next grace period from starting. This last is important in        |
>  | preventing overflow of the ``->exp_wq[]`` array.                      |
> @@ -464,8 +464,8 @@ code need not worry about POSIX signals. Unfortunately, it has the
>  corresponding disadvantage that workqueues cannot be used until they are
>  initialized, which does not happen until some time after the scheduler
>  spawns the first task. Given that there are parts of the kernel that
> -really do want to execute grace periods during this mid-boot “dead
> -zone”, expedited grace periods must do something else during thie time.
> +really do want to execute grace periods during this mid-boot "dead
> +zone", expedited grace periods must do something else during thie time.
>  
>  What they do is to fall back to the old practice of requiring that the
>  requesting task drive the expedited grace period, as was the case before
> diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
> index a648b423ba0e..d76c6bfdc659 100644
> --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
> +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
> @@ -215,7 +215,7 @@ newly arrived RCU callbacks against future grace periods:
>     43 }
>  
>  But the only part of ``rcu_prepare_for_idle()`` that really matters for
> -this discussion are lines 37–39. We will therefore abbreviate this
> +this discussion are lines 37-39. We will therefore abbreviate this
>  function as follows:
>  
>  .. kernel-figure:: rcu_node-lock.svg
> @@ -418,7 +418,7 @@ wait on.
>  | It is indeed not necessary for the grace period to wait on such a     |
>  | critical section. However, it is permissible to wait on it. And it is |
>  | furthermore important to wait on it, as this lazy approach is far     |
> -| more scalable than a “big bang” all-at-once grace-period start could  |
> +| more scalable than a "big bang" all-at-once grace-period start could  |
>  | possibly be.                                                          |
>  +-----------------------------------------------------------------------+
>  
> @@ -448,7 +448,7 @@ proceeds upwards from that point, and the ``rcu_node`` ``->lock``
>  guarantees that the first CPU's quiescent state happens before the
>  remainder of the second CPU's traversal. Applying this line of thought
>  repeatedly shows that all CPUs' quiescent states happen before the last
> -CPU traverses through the root ``rcu_node`` structure, the “last CPU”
> +CPU traverses through the root ``rcu_node`` structure, the "last CPU"
>  being the one that clears the last bit in the root ``rcu_node``
>  structure's ``->qsmask`` field.
>  
> @@ -501,8 +501,8 @@ Forcing Quiescent States
>  
>  As noted above, idle and offline CPUs cannot report their own quiescent
>  states, and therefore the grace-period kernel thread must do the
> -reporting on their behalf. This process is called “forcing quiescent
> -states”, it is repeated every few jiffies, and its ordering effects are
> +reporting on their behalf. This process is called "forcing quiescent
> +states", it is repeated every few jiffies, and its ordering effects are
>  shown below:
>  
>  .. kernel-figure:: TreeRCU-gp-fqs.svg
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
> index 38a39476fc24..a3493b34f3dd 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> @@ -4,7 +4,7 @@ A Tour Through RCU's Requirements
>  
>  Copyright IBM Corporation, 2015
>  
> -Author: Paul E. McKenney
> +Author: Paul E. McKenney
>  
>  The initial version of this document appeared in the
>  `LWN <https://lwn.net/>`_ on those articles:
> @@ -66,7 +66,7 @@ Grace-Period Guarantee
>  
>  RCU's grace-period guarantee is unusual in being premeditated: Jack
>  Slingwine and I had this guarantee firmly in mind when we started work
> -on RCU (then called “rclock”) in the early 1990s. That said, the past
> +on RCU (then called "rclock") in the early 1990s. That said, the past
>  two decades of experience with RCU have produced a much more detailed
>  understanding of this guarantee.
>  
> @@ -102,7 +102,7 @@ overhead to readers, for example:
>        15   WRITE_ONCE(y, 1);
>        16 }
>  
> -Because the synchronize_rcu() on line 14 waits for all pre-existing
> +Because the synchronize_rcu() on line 14 waits for all pre-existing
>  readers, any instance of thread0() that loads a value of zero from
>  ``x`` must complete before thread1() stores to ``y``, so that
>  instance must also load a value of zero from ``y``. Similarly, any
> @@ -178,7 +178,7 @@ little or no synchronization overhead in do_something_dlm().
>  +-----------------------------------------------------------------------+
>  | **Quick Quiz**:                                                       |
>  +-----------------------------------------------------------------------+
> -| Why is the synchronize_rcu() on line 28 needed?                       |
> +| Why is the synchronize_rcu() on line 28 needed?                       |
>  +-----------------------------------------------------------------------+
>  | **Answer**:                                                           |
>  +-----------------------------------------------------------------------+
> @@ -244,7 +244,7 @@ their rights to reorder this code as follows:
>        16 }
>  
>  If an RCU reader fetches ``gp`` just after ``add_gp_buggy_optimized``
> -executes line 11, it will see garbage in the ``->a`` and ``->b`` fields.
> +executes line 11, it will see garbage in the ``->a`` and ``->b`` fields.
>  And this is but one of many ways in which compiler and hardware
>  optimizations could cause trouble. Therefore, we clearly need some way
>  to prevent the compiler and the CPU from reordering in this manner,
> @@ -279,11 +279,11 @@ shows an example of insertion:
>        15   return true;
>        16 }
>  
> -The rcu_assign_pointer() on line 13 is conceptually equivalent to a
> +The rcu_assign_pointer() on line 13 is conceptually equivalent to a
>  simple assignment statement, but also guarantees that its assignment
> -will happen after the two assignments in lines 11 and 12, similar to the
> +will happen after the two assignments in lines 11 and 12, similar to the
>  C11 ``memory_order_release`` store operation. It also prevents any
> -number of “interesting” compiler optimizations, for example, the use of
> +number of "interesting" compiler optimizations, for example, the use of
>  ``gp`` as a scratch location immediately preceding the assignment.
>  
>  +-----------------------------------------------------------------------+
> @@ -410,11 +410,11 @@ This process is implemented by remove_gp_synchronous():
>        15   return true;
>        16 }
>  
> -This function is straightforward, with line 13 waiting for a grace
> -period before line 14 frees the old data element. This waiting ensures
> -that readers will reach line 7 of do_something_gp() before the data
> +This function is straightforward, with line 13 waiting for a grace
> +period before line 14 frees the old data element. This waiting ensures
> +that readers will reach line 7 of do_something_gp() before the data
>  element referenced by ``p`` is freed. The rcu_access_pointer() on
> -line 6 is similar to rcu_dereference(), except that:
> +line 6 is similar to rcu_dereference(), except that:
>  
>  #. The value returned by rcu_access_pointer() cannot be
>     dereferenced. If you want to access the value pointed to as well as
> @@ -488,25 +488,25 @@ systems with more than one CPU:
>     section ends and the time that synchronize_rcu() returns. Without
>     this guarantee, a pre-existing RCU read-side critical section might
>     hold a reference to the newly removed ``struct foo`` after the
> -   kfree() on line 14 of remove_gp_synchronous().
> +   kfree() on line 14 of remove_gp_synchronous().
>  #. Each CPU that has an RCU read-side critical section that ends after
>     synchronize_rcu() returns is guaranteed to execute a full memory
>     barrier between the time that synchronize_rcu() begins and the
>     time that the RCU read-side critical section begins. Without this
>     guarantee, a later RCU read-side critical section running after the
> -   kfree() on line 14 of remove_gp_synchronous() might later run
> +   kfree() on line 14 of remove_gp_synchronous() might later run
>     do_something_gp() and find the newly deleted ``struct foo``.
>  #. If the task invoking synchronize_rcu() remains on a given CPU,
>     then that CPU is guaranteed to execute a full memory barrier sometime
>     during the execution of synchronize_rcu(). This guarantee ensures
> -   that the kfree() on line 14 of remove_gp_synchronous() really
> -   does execute after the removal on line 11.
> +   that the kfree() on line 14 of remove_gp_synchronous() really
> +   does execute after the removal on line 11.
>  #. If the task invoking synchronize_rcu() migrates among a group of
>     CPUs during that invocation, then each of the CPUs in that group is
>     guaranteed to execute a full memory barrier sometime during the
>     execution of synchronize_rcu(). This guarantee also ensures that
> -   the kfree() on line 14 of remove_gp_synchronous() really does
> -   execute after the removal on line 11, but also in the case where the
> +   the kfree() on line 14 of remove_gp_synchronous() really does
> +   execute after the removal on line 11, but also in the case where the
>     thread executing the synchronize_rcu() migrates in the meantime.
>  
>  +-----------------------------------------------------------------------+
> @@ -525,8 +525,8 @@ systems with more than one CPU:
>  | In other words, a given instance of synchronize_rcu() can avoid       |
>  | waiting on a given RCU read-side critical section only if it can      |
>  | prove that synchronize_rcu() started first.                           |
> -| A related question is “When rcu_read_lock() doesn't generate any      |
> -| code, why does it matter how it relates to a grace period?” The       |
> +| A related question is "When rcu_read_lock() doesn't generate any      |
> +| code, why does it matter how it relates to a grace period?" The       |
>  | answer is that it is not the relationship of rcu_read_lock()          |
>  | itself that is important, but rather the relationship of the code     |
>  | within the enclosed RCU read-side critical section to the code        |
> @@ -538,7 +538,7 @@ systems with more than one CPU:
>  | of any access following the grace period.                             |
>  |                                                                       |
>  | As of late 2016, mathematical models of RCU take this viewpoint, for  |
> -| example, see slides 62 and 63 of the `2016 LinuxCon                   |
> +| example, see slides 62 and 63 of the `2016 LinuxCon                   |
>  | EU <http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.201 |
>  | 6.10.04c.LCE.pdf>`__                                                  |
>  | presentation.                                                         |
> @@ -584,9 +584,9 @@ systems with more than one CPU:
>  |                                                                       |
>  | And similarly, without a memory barrier between the beginning of the  |
>  | grace period and the beginning of the RCU read-side critical section, |
> -| CPU 1 might end up accessing the freelist.                            |
> +| CPU 1 might end up accessing the freelist.                            |
>  |                                                                       |
> -| The “as if” rule of course applies, so that any implementation that   |
> +| The "as if" rule of course applies, so that any implementation that   |
>  | acts as if the appropriate memory barriers were in place is a correct |
>  | implementation. That said, it is much easier to fool yourself into    |
>  | believing that you have adhered to the as-if rule than it is to       |
> @@ -1002,7 +1002,7 @@ RCU implementation must abide by them. They therefore bear repeating:
>     ECC errors, NMIs, and other hardware events. Although a delay of more
>     than about 20 seconds can result in splats, the RCU implementation is
>     obligated to use algorithms that can tolerate extremely long delays,
> -   but where “extremely long” is not long enough to allow wrap-around
> +   but where "extremely long" is not long enough to allow wrap-around
>     when incrementing a 64-bit counter.
>  #. Both the compiler and the CPU can reorder memory accesses. Where it
>     matters, RCU must use compiler directives and memory-barrier
> @@ -1169,7 +1169,7 @@ Energy efficiency is a critical component of performance today, and
>  Linux-kernel RCU implementations must therefore avoid unnecessarily
>  awakening idle CPUs. I cannot claim that this requirement was
>  premeditated. In fact, I learned of it during a telephone conversation
> -in which I was given “frank and open” feedback on the importance of
> +in which I was given "frank and open" feedback on the importance of
>  energy efficiency in battery-powered systems and on specific
>  energy-efficiency shortcomings of the Linux-kernel RCU implementation.
>  In my experience, the battery-powered embedded community will consider
> @@ -1234,7 +1234,7 @@ requirements: A storm of synchronize_rcu_expedited() invocations on
>  4096 CPUs should at least make reasonable forward progress. In return
>  for its shorter latencies, synchronize_rcu_expedited() is permitted
>  to impose modest degradation of real-time latency on non-idle online
> -CPUs. Here, “modest” means roughly the same latency degradation as a
> +CPUs. Here, "modest" means roughly the same latency degradation as a
>  scheduling-clock interrupt.
>  
>  There are a number of situations where even
> @@ -1274,8 +1274,8 @@ be used in place of synchronize_rcu() as follows:
>        28 }
>  
>  A definition of ``struct foo`` is finally needed, and appears on
> -lines 1-5. The function remove_gp_cb() is passed to call_rcu()
> -on line 25, and will be invoked after the end of a subsequent grace
> +lines 1-5. The function remove_gp_cb() is passed to call_rcu()
> +on line 25, and will be invoked after the end of a subsequent grace
>  period. This gets the same effect as remove_gp_synchronous(), but
>  without forcing the updater to wait for a grace period to elapse. The
>  call_rcu() function may be used in a number of situations where
> @@ -1294,23 +1294,23 @@ threads or (in the Linux kernel) workqueues.
>  +-----------------------------------------------------------------------+
>  | **Quick Quiz**:                                                       |
>  +-----------------------------------------------------------------------+
> -| Why does line 19 use rcu_access_pointer()? After all,                 |
> -| call_rcu() on line 25 stores into the structure, which would          |
> +| Why does line 19 use rcu_access_pointer()? After all,                 |
> +| call_rcu() on line 25 stores into the structure, which would          |
>  | interact badly with concurrent insertions. Doesn't this mean that     |
>  | rcu_dereference() is required?                                        |
>  +-----------------------------------------------------------------------+
>  | **Answer**:                                                           |
>  +-----------------------------------------------------------------------+
> -| Presumably the ``->gp_lock`` acquired on line 18 excludes any         |
> +| Presumably the ``->gp_lock`` acquired on line 18 excludes any         |
>  | changes, including any insertions that rcu_dereference() would        |
>  | protect against. Therefore, any insertions will be delayed until      |
> -| after ``->gp_lock`` is released on line 25, which in turn means that  |
> +| after ``->gp_lock`` is released on line 25, which in turn means that  |
>  | rcu_access_pointer() suffices.                                        |
>  +-----------------------------------------------------------------------+
>  
>  However, all that remove_gp_cb() is doing is invoking kfree() on
>  the data element. This is a common idiom, and is supported by
> -kfree_rcu(), which allows “fire and forget” operation as shown
> +kfree_rcu(), which allows "fire and forget" operation as shown
>  below:
>  
>     ::
> @@ -1396,8 +1396,8 @@ may be used for this purpose, as shown below:
>        18   return true;
>        19 }
>  
> -On line 14, get_state_synchronize_rcu() obtains a “cookie” from RCU,
> -then line 15 carries out other tasks, and finally, line 16 returns
> +On line 14, get_state_synchronize_rcu() obtains a "cookie" from RCU,
> +then line 15 carries out other tasks, and finally, line 16 returns
>  immediately if a grace period has elapsed in the meantime, but otherwise
>  waits as required. The need for ``get_state_synchronize_rcu`` and
>  cond_synchronize_rcu() has appeared quite recently, so it is too
> @@ -1420,9 +1420,9 @@ example, an infinite loop in an RCU read-side critical section must by
>  definition prevent later grace periods from ever completing. For a more
>  involved example, consider a 64-CPU system built with
>  ``CONFIG_RCU_NOCB_CPU=y`` and booted with ``rcu_nocbs=1-63``, where
> -CPUs 1 through 63 spin in tight loops that invoke call_rcu(). Even
> +CPUs 1 through 63 spin in tight loops that invoke call_rcu(). Even
>  if these tight loops also contain calls to cond_resched() (thus
> -allowing grace periods to complete), CPU 0 simply will not be able to
> +allowing grace periods to complete), CPU 0 simply will not be able to
>  invoke callbacks as fast as the other 63 CPUs can register them, at
>  least not until the system runs out of memory. In both of these
>  examples, the Spiderman principle applies: With great power comes great
> @@ -1433,7 +1433,7 @@ callbacks.
>  RCU takes the following steps to encourage timely completion of grace
>  periods:
>  
> -#. If a grace period fails to complete within 100 milliseconds, RCU
> +#. If a grace period fails to complete within 100 milliseconds, RCU
>     causes future invocations of cond_resched() on the holdout CPUs
>     to provide an RCU quiescent state. RCU also causes those CPUs'
>     need_resched() invocations to return ``true``, but only after the
> @@ -1442,12 +1442,12 @@ periods:
>     indefinitely in the kernel without scheduling-clock interrupts, which
>     defeats the above need_resched() strategem. RCU will therefore
>     invoke resched_cpu() on any ``nohz_full`` CPUs still holding out
> -   after 109 milliseconds.
> +   after 109 milliseconds.
>  #. In kernels built with ``CONFIG_RCU_BOOST=y``, if a given task that
>     has been preempted within an RCU read-side critical section is
> -   holding out for more than 500 milliseconds, RCU will resort to
> +   holding out for more than 500 milliseconds, RCU will resort to
>     priority boosting.
> -#. If a CPU is still holding out 10 seconds into the grace period, RCU
> +#. If a CPU is still holding out 10 seconds into the grace period, RCU
>     will invoke resched_cpu() on it regardless of its ``nohz_full``
>     state.
>  
> @@ -1579,7 +1579,7 @@ period.
>  Software-Engineering Requirements
>  ---------------------------------
>  
> -Between Murphy's Law and “To err is human”, it is necessary to guard
> +Between Murphy's Law and "To err is human", it is necessary to guard
>  against mishaps and misuse:
>  
>  #. It is all too easy to forget to use rcu_read_lock() everywhere
> @@ -1626,7 +1626,7 @@ against mishaps and misuse:
>     `patch <https://lore.kernel.org/r/20100319013024.GA28456@Krystal>`__.
>  #. An infinite loop in an RCU read-side critical section will eventually
>     trigger an RCU CPU stall warning splat, with the duration of
> -   “eventually” being controlled by the ``RCU_CPU_STALL_TIMEOUT``
> +   "eventually" being controlled by the ``RCU_CPU_STALL_TIMEOUT``
>     ``Kconfig`` option, or, alternatively, by the
>     ``rcupdate.rcu_cpu_stall_timeout`` boot/sysfs parameter. However, RCU
>     is not obligated to produce this splat unless there is a grace period
> @@ -1704,7 +1704,7 @@ Configuration
>  
>  RCU's goal is automatic configuration, so that almost nobody needs to
>  worry about RCU's ``Kconfig`` options. And for almost all users, RCU
> -does in fact work well “out of the box.”
> +does in fact work well "out of the box."
>  
>  However, there are specialized use cases that are handled by kernel boot
>  parameters and ``Kconfig`` options. Unfortunately, the ``Kconfig``
> @@ -1733,7 +1733,7 @@ listings.
>  
>  RCU must therefore wait for a given CPU to actually come online before
>  it can allow itself to believe that the CPU actually exists. The
> -resulting “ghost CPUs” (which are never going to come online) cause a
> +resulting "ghost CPUs" (which are never going to come online) cause a
>  number of `interesting
>  complications <https://paulmck.livejournal.com/37494.html>`__.
>  
> @@ -1789,7 +1789,7 @@ normally.
>  | **Answer**:                                                           |
>  +-----------------------------------------------------------------------+
>  | Very carefully!                                                       |
> -| During the “dead zone” between the time that the scheduler spawns the |
> +| During the "dead zone" between the time that the scheduler spawns the |
>  | first task and the time that all of RCU's kthreads have been spawned, |
>  | all synchronous grace periods are handled by the expedited            |
>  | grace-period mechanism. At runtime, this expedited mechanism relies   |
> @@ -1824,7 +1824,7 @@ Some Linux-kernel architectures can enter an interrupt handler from
>  non-idle process context, and then just never leave it, instead
>  stealthily transitioning back to process context. This trick is
>  sometimes used to invoke system calls from inside the kernel. These
> -“half-interrupts” mean that RCU has to be very careful about how it
> +"half-interrupts" mean that RCU has to be very careful about how it
>  counts interrupt nesting levels. I learned of this requirement the hard
>  way during a rewrite of RCU's dyntick-idle code.
>  
> @@ -1921,7 +1921,7 @@ and go. It is of course illegal to use any RCU API member from an
>  offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side
>  critical sections. This requirement was present from day one in
>  DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug
> -implementation is “interesting.”
> +implementation is "interesting."
>  
>  The Linux-kernel CPU-hotplug implementation has notifiers that are used
>  to allow the various kernel subsystems (including RCU) to respond
> @@ -2268,7 +2268,7 @@ remain zero during all phases of grace-period processing, and that bit
>  happens to map to the bottom bit of the ``rcu_head`` structure's
>  ``->next`` field. RCU makes this guarantee as long as call_rcu() is
>  used to post the callback, as opposed to kfree_rcu() or some future
> -“lazy” variant of call_rcu() that might one day be created for
> +"lazy" variant of call_rcu() that might one day be created for
>  energy-efficiency purposes.
>  
>  That said, there are limits. RCU requires that the ``rcu_head``
> @@ -2281,7 +2281,7 @@ architecture provides only two-byte alignment, and thus acts as
>  alignment's least common denominator.
>  
>  The reason for reserving the bottom bit of pointers to ``rcu_head``
> -structures is to leave the door open to “lazy” callbacks whose
> +structures is to leave the door open to "lazy" callbacks whose
>  invocations can safely be deferred. Deferring invocation could
>  potentially have energy-efficiency benefits, but only if the rate of
>  non-lazy callbacks decreases significantly for some important workload.
> @@ -2354,8 +2354,8 @@ which in practice also means that RCU must have an aggressive
>  stress-test suite. This stress-test suite is called ``rcutorture``.
>  
>  Although the need for ``rcutorture`` was no surprise, the current
> -immense popularity of the Linux kernel is posing interesting—and perhaps
> -unprecedented—validation challenges. To see this, keep in mind that
> +immense popularity of the Linux kernel is posing interesting-and perhaps
> +unprecedented-validation challenges. To see this, keep in mind that
>  there are well over one billion instances of the Linux kernel running
>  today, given Android smartphones, Linux-powered televisions, and
>  servers. This number can be expected to increase sharply with the advent
> @@ -2399,7 +2399,7 @@ single flavor. The read-side API remains, and continues to disable
>  softirq and to be accounted for by lockdep. Much of the material in this
>  section is therefore strictly historical in nature.
>  
> -The softirq-disable (AKA “bottom-half”, hence the “_bh” abbreviations)
> +The softirq-disable (AKA "bottom-half", hence the "_bh" abbreviations)
>  flavor of RCU, or *RCU-bh*, was developed by Dipankar Sarma to provide a
>  flavor of RCU that could withstand the network-based denial-of-service
>  attacks researched by Robert Olsson. These attacks placed so much
> @@ -2458,7 +2458,7 @@ effect of also waiting for all pre-existing interrupt and NMI handlers.
>  However, there are legitimate preemptible-RCU implementations that do
>  not have this property, given that any point in the code outside of an
>  RCU read-side critical section can be a quiescent state. Therefore,
> -*RCU-sched* was created, which follows “classic” RCU in that an
> +*RCU-sched* was created, which follows "classic" RCU in that an
>  RCU-sched grace period waits for pre-existing interrupt and NMI
>  handlers. In kernels built with ``CONFIG_PREEMPTION=n``, the RCU and
>  RCU-sched APIs have identical implementations, while kernels built with
> @@ -2490,8 +2490,8 @@ and local_irq_restore(), and so on.
>  Sleepable RCU
>  ~~~~~~~~~~~~~
>  
> -For well over a decade, someone saying “I need to block within an RCU
> -read-side critical section” was a reliable indication that this someone
> +For well over a decade, someone saying "I need to block within an RCU
> +read-side critical section" was a reliable indication that this someone
>  did not understand RCU. After all, if you are always blocking in an RCU
>  read-side critical section, you can probably afford to use a
>  higher-overhead synchronization mechanism. However, that changed with
> @@ -2507,7 +2507,7 @@ this structure must be passed in to each SRCU function, for example,
>  structure. The key benefit of these domains is that a slow SRCU reader
>  in one domain does not delay an SRCU grace period in some other domain.
>  That said, one consequence of these domains is that read-side code must
> -pass a “cookie” from srcu_read_lock() to srcu_read_unlock(), for
> +pass a "cookie" from srcu_read_lock() to srcu_read_unlock(), for
>  example, as follows:
>  
>     ::
> @@ -2536,9 +2536,9 @@ period to elapse. For example, this results in a self-deadlock:
>         5 synchronize_srcu(&ss);
>         6 srcu_read_unlock(&ss, idx);
>  
> -However, if line 5 acquired a mutex that was held across a
> +However, if line 5 acquired a mutex that was held across a
>  synchronize_srcu() for domain ``ss``, deadlock would still be
> -possible. Furthermore, if line 5 acquired a mutex that was held across a
> +possible. Furthermore, if line 5 acquired a mutex that was held across a
>  synchronize_srcu() for some other domain ``ss1``, and if an
>  ``ss1``-domain SRCU read-side critical section acquired another mutex
>  that was held across as ``ss``-domain synchronize_srcu(), deadlock
> @@ -2557,7 +2557,7 @@ memory barrier.
>  Also unlike other RCU flavors, synchronize_srcu() may **not** be
>  invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
>  periods make use of timers and the possibility of timers being
> -temporarily “stranded” on the outgoing CPU. This stranding of timers
> +temporarily "stranded" on the outgoing CPU. This stranding of timers
>  means that timers posted to the outgoing CPU will not fire until late in
>  the CPU-hotplug process. The problem is that if a notifier is waiting on
>  an SRCU grace period, that grace period is waiting on a timer, and that
> @@ -2573,7 +2573,7 @@ period has the side effect of expediting all prior grace periods that
>  have not yet completed. (But please note that this is a property of the
>  current implementation, not necessarily of future implementations.) In
>  addition, if SRCU has been idle for longer than the interval specified
> -by the ``srcutree.exp_holdoff`` kernel boot parameter (25 microseconds
> +by the ``srcutree.exp_holdoff`` kernel boot parameter (25 microseconds
>  by default), and if a synchronize_srcu() invocation ends this idle
>  period, that invocation will be automatically expedited.
>  
> @@ -2619,7 +2619,7 @@ from the cache, an SRCU grace period will be very likely to have elapsed.
>  Tasks RCU
>  ~~~~~~~~~
>  
> -Some forms of tracing use “trampolines” to handle the binary rewriting
> +Some forms of tracing use "trampolines" to handle the binary rewriting
>  required to install different types of probes. It would be good to be
>  able to free old trampolines, which sounds like a job for some form of
>  RCU. However, because it is necessary to be able to install a trace
> @@ -2687,7 +2687,7 @@ your architecture should also benefit from the
>  number of CPUs in a socket, NUMA node, or whatever. If the number of
>  CPUs is too large, use a fraction of the number of CPUs. If the number
>  of CPUs is a large prime number, well, that certainly is an
> -“interesting” architectural choice! More flexible arrangements might be
> +"interesting" architectural choice! More flexible arrangements might be
>  considered, but only if ``rcutree.rcu_fanout_leaf`` has proven
>  inadequate, and only if the inadequacy has been demonstrated by a
>  carefully run and realistic system-level workload.
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 27/53] docs: filesystems: f2fs.rst: avoid using UTF-8 chars
  2021-05-10 10:26   ` [f2fs-dev] " Mauro Carvalho Chehab
@ 2021-05-11  3:16     ` Chao Yu
  -1 siblings, 0 replies; 219+ messages in thread
From: Chao Yu @ 2021-05-11  3:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: Jonathan Corbet, linux-kernel, linux-f2fs-devel, Jaegeuk Kim

On 2021/5/10 18:26, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2013 ('–'): EN DASH
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Reviewed-by: Chao Yu <yuchao0@huawei.com>

Thanks,

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 27/53] docs: filesystems: f2fs.rst: avoid using UTF-8 chars
@ 2021-05-11  3:16     ` Chao Yu
  0 siblings, 0 replies; 219+ messages in thread
From: Chao Yu @ 2021-05-11  3:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Doc Mailing List
  Cc: Jaegeuk Kim, linux-f2fs-devel, linux-kernel, Jonathan Corbet

On 2021/5/10 18:26, Mauro Carvalho Chehab wrote:
> While UTF-8 characters can be used at the Linux documentation,
> the best is to use them only when ASCII doesn't offer a good replacement.
> So, replace the occurences of the following UTF-8 characters:
> 
> 	- U+2013 ('–'): EN DASH
> 	- U+201c ('“'): LEFT DOUBLE QUOTATION MARK
> 	- U+201d ('”'): RIGHT DOUBLE QUOTATION MARK
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Reviewed-by: Chao Yu <yuchao0@huawei.com>

Thanks,


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 14:33           ` Edward Cree
                               ` (4 preceding siblings ...)
  (?)
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: Edward Cree
  Cc: Matthew Wilcox, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924@coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 “utf-8 curly commas”[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: Edward Cree
  Cc: Matthew Wilcox, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924@coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 “utf-8 curly commas”[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, Matthew Wilcox, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-integrity, David Woodhouse

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924@coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 “utf-8 curly commas”[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, Matthew Wilcox, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-integrity, David Woodhouse

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924@coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 “utf-8 curly commas”[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: Edward Cree
  Cc: Matthew Wilcox, David Woodhouse, Linux Doc Mailing List,
	linux-kernel, Jonathan Corbet, alsa-devel, coresight, dri-devel,
	intel-gfx, intel-wired-lan, keyrings, kvm, linux-acpi,
	linux-arm-kernel, linux-edac, linux-ext4, linux-f2fs-devel,
	linux-fpga, linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924@coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 “utf-8 curly commas”[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, Matthew Wilcox, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-integrity, David Woodhouse

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924@coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564@kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 “utf-8 curly commas”[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:00             ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:00 UTC (permalink / raw)
  To: intel-wired-lan

Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree <ecree.xilinx@gmail.com> escreveu:

> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).  
> I fully agree with fixing those.
> The cover-letter, however, gave the impression that that was not the
>  main purpose of this series; just, perhaps, a happy side-effect.

Sorry for the mess. The main reason why I wrote this series is because
there are lots of UTF-8 left-over chars from the ReST conversion.
See:
  - https://lore.kernel.org/linux-doc/20210507100435.3095f924 at coco.lan/

A large set of the UTF-8 letf-over chars were due to my conversion work,
so I feel personally responsible to fix those ;-)

Yet, this series has two positive side effects:

 - it helps people needing to touch the documents using non-utf8 locales[1];
 - it makes easier to grep for a text;

[1] There are still some widely used distros nowadays (LTS ones?) that
    don't set UTF-8 as default. Last time I installed a Debian machine
    I had to explicitly set UTF-8 charset after install as the default
    were using ASCII encoding (can't remember if it was Debian 10 or an
    older version).

Unintentionally, I ended by giving emphasis to the non-utf8 instead of
giving emphasis to the conversion left-overs.

FYI, this patch series originated from a discussion at linux-doc,
reporting that Sphinx breaks when LANG is not set to utf-8[2]. That's
why I probably ended giving the wrong emphasis at the cover letter.

[2] See https://lore.kernel.org/linux-doc/20210506103913.GE6564 at kitsune.suse.cz/
    for the original report. I strongly suspect that the VM set by Michal 
    to build the docs was using a distro that doesn't set UTF-8 as default.

    PS.: 
      I intend to prepare afterwards a separate fix to avoid Sphinx
      logger to crash during Kernel doc builds when the locale charset
      is not UTF-8, but I'm not too fluent in python. So, I need some
      time to check if are there a way to just avoid python log crashes
      without touching Sphinx code and without needing to trick it to 
      think that the machine's locale is UTF-8.

See: while there was just a single document originally stored at the
Kernel tree as a LaTeX document during the time we did the conversion
(cdrom-standard.tex), there are several other documents stored as 
text that seemed to be generated by some tool like LaTeX, whose the
original version were not preserved. 

Also, there were other documents using different markdown dialects 
that were converted via pandoc (and/or other similar tools). That's 
not to mention the ones that were converted from DocBook. Such
tools tend to use some logic to use "neat" versions of some ASCII
characters, like what this tool does:

	https://daringfireball.net/projects/smartypants/

(Sphinx itself seemed to use this tool on its early versions)

All tool-converted documents can carry UTF-8 on unexpected places. See,
on this series, a large amount of patches deal with U+A0 (NO-BREAK SPACE)
chars. I can't see why someone writing a plain text document (or a ReST
one) would type a NO-BREAK SPACE instead of a normal white space.

The same applies, up to some sort, to curly commas: usually people just 
write ASCII "commas" on their documents, and use some tool like LaTeX
or a text editor like libreoffice in order to convert them into
 ?utf-8 curly commas?[3].

[3] Sphinx will do such things at the produced output, doing something 
    similar to what smartypants does, nowadays using this:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

    E. g.:
      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

> > You seem quite knowedgeable about the various differences.  Perhaps
> > you'd be willing to write a document for Documentation/doc-guide/
> > that provides guidance for when to use which kinds of horizontal
> > line?
> I have Opinions about the proper usage of punctuation, but I also know  
>  that other people have differing opinions.  For instance, I place
>  spaces around an em dash, which is nonstandard according to most
>  style guides.  Really this is an individual enough thing that I'm not
>  sure we could have a "kernel style guide" that would be more useful
>  than general-purpose guidance like the page you linked.

> Moreover, such a guide could make non-native speakers needlessly self-
>  conscious about their writing and discourage them from contributing
>  documentation at all.

I don't think so. In a matter of fact, as a non-native speaker, I guess
this can actually help people willing to write documents.

>  I'm not advocating here for trying to push
>  kernel developers towards an eats-shoots-and-leaves level of
>  linguistic pedantry; rather, I merely think that existing correct
>  usages should be left intact (and therefore, excising incorrect usage
>  should only be attempted by someone with both the expertise and time
>  to check each case).
> 
> But if you really want such a doc I wouldn't mind contributing to it.

IMO, a document like that can be helpful. I can help reviewing it.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-11  9:00             ` Mauro Carvalho Chehab
                                 ` (3 preceding siblings ...)
  (?)
@ 2021-05-11  9:19               ` David Woodhouse
  -1 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-11  9:19 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Edward Cree
  Cc: Matthew Wilcox, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
> 
>  - it helps people needing to touch the documents using non-utf8 locales[1];
>  - it makes easier to grep for a text;
> 
> [1] There are still some widely used distros nowadays (LTS ones?) that
>     don't set UTF-8 as default. Last time I installed a Debian machine
>     I had to explicitly set UTF-8 charset after install as the default
>     were using ASCII encoding (can't remember if it was Debian 10 or an
>     older version).

This whole line of thinking is fundamentally wrong.

A given set of characters in a "text file" are encoded with a specific
character set / encoding. To interpret that file and convert the bytes
back to characters, we need to use the *same* charset.

That charset is a property of the text file, and each text file or
piece of text in a system (like this email, which will contain a
Content-Type: header indicating the charset) might be encoded with a
*different* character set.

In the days before you could connect computers together — or before you
could exchange data between computers in different countries, at least
— perhaps it made sense to store 'text' files without explicitly noting
their encoding. And to interpret them using some kind of "default"
character set.

Those days are long gone. You're trying to work around an egregiously
stupid bug, if you're trying to pander to "default" encodings. There
*is* no default encoding that even makes sense, except perhaps UTF-8.
To *speak* of them as you did shows a misunderstanding of how broken
they are. It's *precisely* that kind of half-baked thinking which
always used to lead to stupid assumptions and double conversions and
Mojibake. Before we just standardised on UTF-8 everywhere and it
stopped mattering so much.

Just don't.

Now, you *can* make this work if you really insist on it, even for
systems with EBCDIC as their default encoding. Just make git do the
"convert to local charset" on checkout, precisely the same way as it
does CRLF for Windows systems. But it's stupid and anachronistic, so I
don't really see the point.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:19               ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-11  9:19 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Edward Cree
  Cc: Matthew Wilcox, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


[-- Attachment #1.1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
> 
>  - it helps people needing to touch the documents using non-utf8 locales[1];
>  - it makes easier to grep for a text;
> 
> [1] There are still some widely used distros nowadays (LTS ones?) that
>     don't set UTF-8 as default. Last time I installed a Debian machine
>     I had to explicitly set UTF-8 charset after install as the default
>     were using ASCII encoding (can't remember if it was Debian 10 or an
>     older version).

This whole line of thinking is fundamentally wrong.

A given set of characters in a "text file" are encoded with a specific
character set / encoding. To interpret that file and convert the bytes
back to characters, we need to use the *same* charset.

That charset is a property of the text file, and each text file or
piece of text in a system (like this email, which will contain a
Content-Type: header indicating the charset) might be encoded with a
*different* character set.

In the days before you could connect computers together — or before you
could exchange data between computers in different countries, at least
— perhaps it made sense to store 'text' files without explicitly noting
their encoding. And to interpret them using some kind of "default"
character set.

Those days are long gone. You're trying to work around an egregiously
stupid bug, if you're trying to pander to "default" encodings. There
*is* no default encoding that even makes sense, except perhaps UTF-8.
To *speak* of them as you did shows a misunderstanding of how broken
they are. It's *precisely* that kind of half-baked thinking which
always used to lead to stupid assumptions and double conversions and
Mojibake. Before we just standardised on UTF-8 everywhere and it
stopped mattering so much.

Just don't.

Now, you *can* make this work if you really insist on it, even for
systems with EBCDIC as their default encoding. Just make git do the
"convert to local charset" on checkout, precisely the same way as it
does CRLF for Windows systems. But it's stupid and anachronistic, so I
don't really see the point.


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:19               ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-11  9:19 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, Matthew Wilcox, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-integrity

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
> 
>  - it helps people needing to touch the documents using non-utf8 locales[1];
>  - it makes easier to grep for a text;
> 
> [1] There are still some widely used distros nowadays (LTS ones?) that
>     don't set UTF-8 as default. Last time I installed a Debian machine
>     I had to explicitly set UTF-8 charset after install as the default
>     were using ASCII encoding (can't remember if it was Debian 10 or an
>     older version).

This whole line of thinking is fundamentally wrong.

A given set of characters in a "text file" are encoded with a specific
character set / encoding. To interpret that file and convert the bytes
back to characters, we need to use the *same* charset.

That charset is a property of the text file, and each text file or
piece of text in a system (like this email, which will contain a
Content-Type: header indicating the charset) might be encoded with a
*different* character set.

In the days before you could connect computers together — or before you
could exchange data between computers in different countries, at least
— perhaps it made sense to store 'text' files without explicitly noting
their encoding. And to interpret them using some kind of "default"
character set.

Those days are long gone. You're trying to work around an egregiously
stupid bug, if you're trying to pander to "default" encodings. There
*is* no default encoding that even makes sense, except perhaps UTF-8.
To *speak* of them as you did shows a misunderstanding of how broken
they are. It's *precisely* that kind of half-baked thinking which
always used to lead to stupid assumptions and double conversions and
Mojibake. Before we just standardised on UTF-8 everywhere and it
stopped mattering so much.

Just don't.

Now, you *can* make this work if you really insist on it, even for
systems with EBCDIC as their default encoding. Just make git do the
"convert to local charset" on checkout, precisely the same way as it
does CRLF for Windows systems. But it's stupid and anachronistic, so I
don't really see the point.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:19               ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-11  9:19 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Edward Cree
  Cc: Matthew Wilcox, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86


[-- Attachment #1.1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
> 
>  - it helps people needing to touch the documents using non-utf8 locales[1];
>  - it makes easier to grep for a text;
> 
> [1] There are still some widely used distros nowadays (LTS ones?) that
>     don't set UTF-8 as default. Last time I installed a Debian machine
>     I had to explicitly set UTF-8 charset after install as the default
>     were using ASCII encoding (can't remember if it was Debian 10 or an
>     older version).

This whole line of thinking is fundamentally wrong.

A given set of characters in a "text file" are encoded with a specific
character set / encoding. To interpret that file and convert the bytes
back to characters, we need to use the *same* charset.

That charset is a property of the text file, and each text file or
piece of text in a system (like this email, which will contain a
Content-Type: header indicating the charset) might be encoded with a
*different* character set.

In the days before you could connect computers together — or before you
could exchange data between computers in different countries, at least
— perhaps it made sense to store 'text' files without explicitly noting
their encoding. And to interpret them using some kind of "default"
character set.

Those days are long gone. You're trying to work around an egregiously
stupid bug, if you're trying to pander to "default" encodings. There
*is* no default encoding that even makes sense, except perhaps UTF-8.
To *speak* of them as you did shows a misunderstanding of how broken
they are. It's *precisely* that kind of half-baked thinking which
always used to lead to stupid assumptions and double conversions and
Mojibake. Before we just standardised on UTF-8 everywhere and it
stopped mattering so much.

Just don't.

Now, you *can* make this work if you really insist on it, even for
systems with EBCDIC as their default encoding. Just make git do the
"convert to local charset" on checkout, precisely the same way as it
does CRLF for Windows systems. But it's stupid and anachronistic, so I
don't really see the point.


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:19               ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-11  9:19 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Edward Cree
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, Matthew Wilcox, linux-acpi, intel-wired-lan,
	linux-input, linux-ext4, intel-gfx, linux-media, linux-pm,
	linux-sgx, coresight, rcu, mjpeg-users, linux-arm-kernel,
	linux-edac, linux-hwmon, netdev, linux-usb, linux-kernel,
	linux-f2fs-devel, linux-integrity


[-- Attachment #1.1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
> 
>  - it helps people needing to touch the documents using non-utf8 locales[1];
>  - it makes easier to grep for a text;
> 
> [1] There are still some widely used distros nowadays (LTS ones?) that
>     don't set UTF-8 as default. Last time I installed a Debian machine
>     I had to explicitly set UTF-8 charset after install as the default
>     were using ASCII encoding (can't remember if it was Debian 10 or an
>     older version).

This whole line of thinking is fundamentally wrong.

A given set of characters in a "text file" are encoded with a specific
character set / encoding. To interpret that file and convert the bytes
back to characters, we need to use the *same* charset.

That charset is a property of the text file, and each text file or
piece of text in a system (like this email, which will contain a
Content-Type: header indicating the charset) might be encoded with a
*different* character set.

In the days before you could connect computers together — or before you
could exchange data between computers in different countries, at least
— perhaps it made sense to store 'text' files without explicitly noting
their encoding. And to interpret them using some kind of "default"
character set.

Those days are long gone. You're trying to work around an egregiously
stupid bug, if you're trying to pander to "default" encodings. There
*is* no default encoding that even makes sense, except perhaps UTF-8.
To *speak* of them as you did shows a misunderstanding of how broken
they are. It's *precisely* that kind of half-baked thinking which
always used to lead to stupid assumptions and double conversions and
Mojibake. Before we just standardised on UTF-8 everywhere and it
stopped mattering so much.

Just don't.

Now, you *can* make this work if you really insist on it, even for
systems with EBCDIC as their default encoding. Just make git do the
"convert to local charset" on checkout, precisely the same way as it
does CRLF for Windows systems. But it's stupid and anachronistic, so I
don't really see the point.


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:19               ` David Woodhouse
  0 siblings, 0 replies; 219+ messages in thread
From: David Woodhouse @ 2021-05-11  9:19 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
> 
>  - it helps people needing to touch the documents using non-utf8 locales[1];
>  - it makes easier to grep for a text;
> 
> [1] There are still some widely used distros nowadays (LTS ones?) that
>     don't set UTF-8 as default. Last time I installed a Debian machine
>     I had to explicitly set UTF-8 charset after install as the default
>     were using ASCII encoding (can't remember if it was Debian 10 or an
>     older version).

This whole line of thinking is fundamentally wrong.

A given set of characters in a "text file" are encoded with a specific
character set / encoding. To interpret that file and convert the bytes
back to characters, we need to use the *same* charset.

That charset is a property of the text file, and each text file or
piece of text in a system (like this email, which will contain a
Content-Type: header indicating the charset) might be encoded with a
*different* character set.

In the days before you could connect computers together ? or before you
could exchange data between computers in different countries, at least
? perhaps it made sense to store 'text' files without explicitly noting
their encoding. And to interpret them using some kind of "default"
character set.

Those days are long gone. You're trying to work around an egregiously
stupid bug, if you're trying to pander to "default" encodings. There
*is* no default encoding that even makes sense, except perhaps UTF-8.
To *speak* of them as you did shows a misunderstanding of how broken
they are. It's *precisely* that kind of half-baked thinking which
always used to lead to stupid assumptions and double conversions and
Mojibake. Before we just standardised on UTF-8 everywhere and it
stopped mattering so much.

Just don't.

Now, you *can* make this work if you really insist on it, even for
systems with EBCDIC as their default encoding. Just make git do the
"convert to local charset" on checkout, precisely the same way as it
does CRLF for Windows systems. But it's stupid and anachronistic, so I
don't really see the point.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210511/acf24092/attachment-0001.bin>

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 13:49       ` David Woodhouse
                           ` (4 preceding siblings ...)
  (?)
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
	alsa-devel, coresight, dri-devel, intel-gfx, intel-wired-lan,
	keyrings, kvm, linux-acpi, linux-arm-kernel, linux-edac,
	linux-ext4, linux-f2fs-devel, linux-fpga, linux-hwmon, linux-iio,
	linux-input, linux-integrity, linux-media, linux-pci, linux-pm,
	linux-rdma, linux-riscv, linux-sgx, linux-usb, mjpeg-users,
	netdev, rcu, x86

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: David Woodhouse
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes — which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus — does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:25         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:25 UTC (permalink / raw)
  To: intel-wired-lan

Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8. 
> > 
> > See, a number of converted documents ended with weird characters
> > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > character doesn't do any good.
> > 
> > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > someone tries to use grep[1].  
> 
> Replacing those makes sense. But replacing emdashes ? which are a
> distinct character that has no direct replacement in ASCII and which
> people do *deliberately* use instead of hyphen-minus ? does not.
> 
> Perhaps stick to those two, and any cases where an emdash or endash has
> been used where U+002D HYPHEN-MINUS *should* have been used.

Ok. I'll rework the series excluding EM/EN DASH chars from it.
I'll then apply manually the changes for EM/EN DASH chars 
(probably on a separate series) where it seems to fit. That should
make easier to discuss such replacements.

> And please fix your cover letter which made no reference to 'grep', and
> only presented a completely bogus argument for the change instead.

OK!

Regards,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
  2021-05-10 19:22         ` Theodore Ts'o
                             ` (4 preceding siblings ...)
  (?)
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes — which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus — does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes — which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus — does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [f2fs-dev] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes — which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus — does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes — which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus — does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: David Woodhouse, Linux Doc Mailing List, linux-kernel,
	Jonathan Corbet, alsa-devel, coresight, dri-devel, intel-gfx,
	intel-wired-lan, keyrings, kvm, linux-acpi, linux-arm-kernel,
	linux-edac, linux-ext4, linux-f2fs-devel, linux-fpga,
	linux-hwmon, linux-iio, linux-input, linux-integrity,
	linux-media, linux-pci, linux-pm, linux-rdma, linux-riscv,
	linux-sgx, linux-usb, mjpeg-users, netdev, rcu, x86

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes — which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus — does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: Theodore Ts'o
  Cc: alsa-devel, kvm, Linux Doc Mailing List, linux-iio, linux-pci,
	linux-fpga, dri-devel, keyrings, linux-riscv, Jonathan Corbet,
	linux-rdma, x86, linux-acpi, intel-wired-lan, linux-input,
	linux-ext4, intel-gfx, linux-media, linux-pm, linux-sgx,
	coresight, rcu, mjpeg-users, linux-arm-kernel, linux-edac,
	linux-hwmon, netdev, linux-usb, linux-kernel, linux-f2fs-devel,
	linux-integrity, David Woodhouse

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes — which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus — does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 219+ messages in thread

* [Intel-wired-lan] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII
@ 2021-05-11  9:37           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-11  9:37 UTC (permalink / raw)
  To: intel-wired-lan

Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" <tytso@mit.edu> escreveu:

> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:  
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using UTF-8. 
> > > 
> > > See, a number of converted documents ended with weird characters
> > > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specific
> > > character doesn't do any good.
> > > 
> > > Others use NO-BREAK SPACE (U+A0) instead of 0x20. Harmless, until
> > > someone tries to use grep[1].  
> > 
> > Replacing those makes sense. But replacing emdashes ? which are a
> > distinct character that has no direct replacement in ASCII and which
> > people do *deliberately* use instead of hyphen-minus ? does not.  
> 
> I regularly use --- for em-dashes and -- for en-dashes.  Markdown will
> automatically translate 3 ASCII hypens to em-dashes, and 2 ASCII
> hyphens to en-dashes.  It's much, much easier for me to type 2 or 3
> hypens into my text editor of choice than trying to enter the UTF-8
> characters. 

Yeah, typing those UTF-8 chars are a lot harder than typing -- and ---
on several text editors ;-)

Here, I only type UTF-8 chars for accents (my US-layout keyboards are 
all set to US international, so typing those are easy).

> If we can make sphinx do this translation, maybe that's
> the best way of dealing with these two characters?

Sphinx already does that by default[1], using smartquotes:

	https://docutils.sourceforge.io/docs/user/smartquotes.html

Those are the conversions that are done there:

      - Straight quotes (" and ') turned into "curly" quote characters;
      - dashes (-- and ---) turned into en- and em-dash entities;
      - three consecutive dots (... or . . .) turned into an ellipsis char.

So, we can simply use single/double commas, hyphens and dots for
curly commas and ellipses.

[1] There's a way to disable it at conf.py, but at the Kernel this is
    kept on its default: to automatically do such conversions. 

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 39/53] docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  2021-05-10 23:35   ` David Gow
@ 2021-05-12  8:14     ` Mauro Carvalho Chehab
  2021-05-12  8:29     ` Mauro Carvalho Chehab
  1 sibling, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-12  8:14 UTC (permalink / raw)
  To: David Gow
  Cc: Linux Doc Mailing List, Jonathan Corbet, Daniel Latypov,
	Marco Elver, Linux Kernel Mailing List

Em Tue, 11 May 2021 07:35:29 +0800
David Gow <davidgow@google.com> escreveu:

> On Mon, May 10, 2021 at 6:27 PM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > While UTF-8 characters can be used at the Linux documentation,
> > the best is to use them only when ASCII doesn't offer a good replacement.
> > So, replace the occurences of the following UTF-8 characters:
> >
> >         - U+2014 ('—'): EM DASH
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---  
> 
> Oh dear, I do have a habit of overusing em-dashes. I've no problem in
> theory with exchanging them for an ASCII approximation.
> I suppose there's a reason it's the one dash to rule them all: :-)
> https://twitter.com/FakeUnicode/status/727888721312260096/photo/1

No, there's no such rule, although there's a preference to keep
the texts easy to edit/read as text files[1]. The main rationale for
this series is that the conversion from other formats to ReST ended
introducing a lot of UTF-8 noise.

[1] IMO, the best is to use UTF-8 characters for symbols that
    aren't properly represented in ASCII, like Latin accents,
    Greek letters, etc.

In the specific case of dashes, you can use:

	"--" for EN DASH
	"---" for EM DASH

Those will automatically be translated by Sphinx when building 
the docs. Using ASCII there usually makes life simpler for
developers whose editors can't easily type EN/EM DASH.

Btw, Sphinx will also replace commas to curly commas
automatically on its output (except for literal blocks).

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 39/53] docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  2021-05-10 23:35   ` David Gow
  2021-05-12  8:14     ` Mauro Carvalho Chehab
@ 2021-05-12  8:29     ` Mauro Carvalho Chehab
  1 sibling, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-12  8:29 UTC (permalink / raw)
  To: David Gow
  Cc: Linux Doc Mailing List, Jonathan Corbet, Daniel Latypov,
	Marco Elver, Linux Kernel Mailing List

Em Tue, 11 May 2021 07:35:29 +0800
David Gow <davidgow@google.com> escreveu:

> On Mon, May 10, 2021 at 6:27 PM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > While UTF-8 characters can be used at the Linux documentation,
> > the best is to use them only when ASCII doesn't offer a good replacement.
> > So, replace the occurences of the following UTF-8 characters:
> >
> >         - U+2014 ('—'): EM DASH
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---  
> 
> Oh dear, I do have a habit of overusing em-dashes. I've no problem in
> theory with exchanging them for an ASCII approximation.
> I suppose there's a reason it's the one dash to rule them all: :-)
> https://twitter.com/FakeUnicode/status/727888721312260096/photo/1
> 
> >  Documentation/dev-tools/testing-overview.rst | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
> > index b5b46709969c..8adffc26a2ec 100644
> > --- a/Documentation/dev-tools/testing-overview.rst
> > +++ b/Documentation/dev-tools/testing-overview.rst
> > @@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
> >  groups of tests easier, as well as providing helpers to aid in writing new
> >  tests.
> >
> > -If you're looking to verify the behaviour of the Kernel — particularly specific
> > -parts of the kernel — then you'll want to use KUnit or kselftest.
> > +If you're looking to verify the behaviour of the Kernel - particularly specific
> > +parts of the kernel - then you'll want to use KUnit or kselftest.  
> 
> As Marco pointed out, having multiple HYPHEN-MINUS symbols in a row is
> probably a better replacement, as it does distinguish the em-dash from
> smaller dashes better.
> However, I need three for sphinx to output an em-dash here (2 hyphens
> only gives me an en-dash).
> 
> So, if we want to get rid of the UTF-8 em-dash, my preferences would
> be (in descending order):
> 1. Three hyphens: '---' (sphinx generates an em-dash)
> 2. Two hyphens: '--' (worst case, an en-dash surrounded by spaces --
> as sphinx generates for me -- is still readable, and it's still
> readable as an em-dash in plain text)
> 3. One hyphen as in this patch (which I don't like as much, but will
> no doubt learn to live with)
> 
> But it looks like you've got several similar comments on other patches
> in this series, so I'm happy for you to use whatever ends up being
> agreed upon generally.

Yeah, from the comments I received so far, it seems that most developers
want to use '---' for EM DASH and '--' for EN DASH, typing it as ASCII
instead of using U+<number> as this is easier on most editors.

Yet, my understanding is that we don't have a consensus with that
regards, as some patches I sent using a single hyphen were 
accepted/reviewed/acked.

So, I sent (and it was already applied) a small patch series (/5)
fixing the cases where UTF-8 chars (including DASH) were added
by mistake (probably due to some conversion tool). 

For the remaining issues, my plan is to split this series in two
parts:

The first one with non-polemic UTF-8 changes, and a second one with
just EM/EN DASH, using '---' to replace EM DASH and '--' to replace
EN DASH, as this way, the produced HTML/LaTeX/PDF docs won't change.

This should make easier to discuss the EM/EN DASH changes on
each patch, and see if the above default is the better fit for a
particular usecase.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 06/53] docs: admin-guide: avoid using UTF-8 chars
  2021-05-10 18:40   ` Gabriel Krisman Bertazi
@ 2021-05-12  8:44     ` Mauro Carvalho Chehab
  2021-05-12  9:25       ` David Woodhouse
  0 siblings, 1 reply; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-12  8:44 UTC (permalink / raw)
  To: Gabriel Krisman Bertazi
  Cc: Linux Doc Mailing List, Daniel W. S. Almeida, Jonathan Corbet,
	Arnd Bergmann, Borislav Petkov, David Howells, David Woodhouse,
	Greg Kroah-Hartman, James Morse, Kees Cook,
	Mauro Carvalho Chehab, Robert Richter, Thorsten Leemhuis,
	Tony Luck, keyrings, linux-edac, linux-kernel

Em Mon, 10 May 2021 14:40:09 -0400
Gabriel Krisman Bertazi <krisman@collabora.com> escreveu:

> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> 
> > While UTF-8 characters can be used at the Linux documentation,
> > the best is to use them only when ASCII doesn't offer a good replacement.
> > So, replace the occurences of the following UTF-8 characters:
> >
> > 	- U+00a0 (' '): NO-BREAK SPACE
> > 	- U+2013 ('–'): EN DASH
> > 	- U+2014 ('—'): EM DASH
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> >  Documentation/admin-guide/index.rst           |  2 +-
> >  Documentation/admin-guide/module-signing.rst  |  4 +-
> >  Documentation/admin-guide/ras.rst             | 94 +++++++++----------
> >  .../admin-guide/reporting-issues.rst          | 12 +--
> >  4 files changed, 56 insertions(+), 56 deletions(-)  
> 
> Hi Mauro,
> 
> This patch misses one occurrence of U+2014 in
> Documentation/admin-guide/sysctl/kernel.rst:1288.

It ended to be on a separate patch.

> There are also countless occurrences in Documentation/, outside of
> Documentation/admin-guide.  I suppose another patch in the series, which
> I didn't receive, will fix them?

Yes. This series should fix all occurrences inside Documentation/ on
*.rst files and on ABI, except for Documentation/translations[1].

[1] Still it probably makes sense to do a subset of the changes
from this series there, but touching non-Latin translations are riskier.

> These characters will just reappear elsewhere, eventually. I'm not sure
> what is the gain here, other than minor consistence improvements.

The main point here is that a large amount of those UTF-8 characters
appeared as result of document conversion from DocBook/LaTeX/Markdown.

As the conversion ended, I don't expect the need of re-doing a series
like that in the near future.

There are even some cases where the UTF-8 were doing wrong things, like
using an EN DASH instead of an hyphen in order to pass a command line
parameter, and the addition of non-printable BOM characters.

So, IMO, this is a necessarily cleanup after the conversion.

> But we
> should add a Warning during documentation generation (if there isn't one
> already), to prevent them from spreading again.

Not sure if it is worth... See: people can (and should) use UTF-8
characters when needed, like for instance using Latin accented 
characters on names and translations, and use Greek letters when
pertinent, like using MICRO SIGN or GREEK SMALL LETTER MU to
represent microsseconds.

On the other hand, using curly commas instead of ASCII ones and
dashes instead of -- and --- only makes harder for people to type
documents with normal editors without any gain, as Sphinx already
convert those into curly commas and EN/EM DASH when it generates 
html/pdf docs.


Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 12/53] docs: driver-api: avoid using UTF-8 chars
       [not found]   ` <CAHp75Vegsb-+fVppv3C7Jp0a=mEGAh2pchX=Cr5ZvOMFt+G73Q@mail.gmail.com>
@ 2021-05-12  8:49     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-12  8:49 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Linux Doc Mailing List, Jonathan Corbet, Andy Shevchenko,
	Dan Williams, Dave Ertman, Drew Fustini, Greg Kroah-Hartman,
	Hans de Goede, Heikki Krogerus, Jacob Keller, Michael Walle,
	Philipp Zabel, linux-kernel

Em Mon, 10 May 2021 14:05:12 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> escreveu:

> On Monday, May 10, 2021, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> wrote:
> 
> > While UTF-8 characters can be used at the Linux documentation,
> > the best is to use them only when ASCII doesn't offer a good replacement.
> > So, replace the occurences of the following UTF-8 characters:
> >
> >         - U+00a0 (' '): NO-BREAK SPACE
> >         - U+2014 ('—'): EM DASH  
> 
> 
> Strictly speaking the EM Dash equivalent is ‘--‘.

Yes, EM DASH is equivalent to multiple '-'.

Sphinx (and other similar tools) use those rules:

	-- is equivalent to EN DASH;
	--- is equivalent to EM DASH

Anyway, I'll change this on a next spin.

> 
> 
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> >  Documentation/driver-api/index.rst | 2 +-
> >  Documentation/driver-api/ioctl.rst | 8 ++++----
> >  2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/driver-api/index.rst
> > b/Documentation/driver-api/index.rst
> > index f5a3207aa7fa..29eb9230b7a9 100644
> > --- a/Documentation/driver-api/index.rst
> > +++ b/Documentation/driver-api/index.rst
> > @@ -4,7 +4,7 @@ The Linux driver implementer's API guide
> >
> >  The kernel offers a wide variety of interfaces to support the development
> >  of device drivers.  This document is an only somewhat organized collection
> > -of some of those interfaces — it will hopefully get better over time!  The
> > +of some of those interfaces - it will hopefully get better over time!  The
> >  available subsections can be seen below.
> >
> >  .. class:: toc-title
> > diff --git a/Documentation/driver-api/ioctl.rst
> > b/Documentation/driver-api/ioctl.rst
> > index c455db0e1627..5b76e765827d 100644
> > --- a/Documentation/driver-api/ioctl.rst
> > +++ b/Documentation/driver-api/ioctl.rst
> > @@ -25,9 +25,9 @@ ioctl commands that follow modern conventions: ``_IO``,
> > ``_IOR``,
> >  with the correct parameters:
> >
> >  _IO/_IOR/_IOW/_IOWR
> > -   The macro name specifies how the argument will be used.  It may be a
> > +   The macro name specifies how the argument will be used.  It may be a
> >     pointer to data to be passed into the kernel (_IOW), out of the kernel
> > -   (_IOR), or both (_IOWR).  _IO can indicate either commands with no
> > +   (_IOR), or both (_IOWR).  _IO can indicate either commands with no
> >     argument or those passing an integer value instead of a pointer.
> >     It is recommended to only use _IO for commands without arguments,
> >     and use pointers for passing data.
> > @@ -200,10 +200,10 @@ cause an information leak, which can be used to
> > defeat kernel address
> >  space layout randomization (KASLR), helping in an attack.
> >
> >  For this reason (and for compat support) it is best to avoid any
> > -implicit padding in data structures.  Where there is implicit padding
> > +implicit padding in data structures.  Where there is implicit padding
> >  in an existing structure, kernel drivers must be careful to fully
> >  initialize an instance of the structure before copying it to user
> > -space.  This is usually done by calling memset() before assigning to
> > +space.  This is usually done by calling memset() before assigning to
> >  individual members.
> >
> >  Subsystem abstractions
> > --
> > 2.30.2
> >
> >  
> 



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 39/53] docs: dev-tools: testing-overview.rst: avoid using UTF-8 chars
  2021-05-10 10:48   ` Marco Elver
@ 2021-05-12  8:52     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-12  8:52 UTC (permalink / raw)
  To: Marco Elver
  Cc: Linux Doc Mailing List, Jonathan Corbet, Daniel Latypov, David Gow, LKML

Em Mon, 10 May 2021 12:48:22 +0200
Marco Elver <elver@google.com> escreveu:

> On Mon, 10 May 2021 at 12:27, Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > While UTF-8 characters can be used at the Linux documentation,
> > the best is to use them only when ASCII doesn't offer a good replacement.
> > So, replace the occurences of the following UTF-8 characters:
> >
> >         - U+2014 ('—'): EM DASH
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> >  Documentation/dev-tools/testing-overview.rst | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
> > index b5b46709969c..8adffc26a2ec 100644
> > --- a/Documentation/dev-tools/testing-overview.rst
> > +++ b/Documentation/dev-tools/testing-overview.rst
> > @@ -18,8 +18,8 @@ frameworks. These both provide infrastructure to help make running tests and
> >  groups of tests easier, as well as providing helpers to aid in writing new
> >  tests.
> >
> > -If you're looking to verify the behaviour of the Kernel — particularly specific
> > -parts of the kernel — then you'll want to use KUnit or kselftest.
> > +If you're looking to verify the behaviour of the Kernel - particularly specific
> > +parts of the kernel - then you'll want to use KUnit or kselftest.  
> 
> Single dash is incorrect punctuation here. So that Sphinx gives us the
> correct em dash, these should be '--'.

On Sphinx[1]:

	-- is equivalent to EN DASH;
	--- is equivalent to EM DASH.

[1] https://docutils.sourceforge.io/docs/user/smartquotes.html

I'll change this on a next spin.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 06/53] docs: admin-guide: avoid using UTF-8 chars
  2021-05-12  8:44     ` Mauro Carvalho Chehab
@ 2021-05-12  9:25       ` David Woodhouse
  2021-05-12 10:22         ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 219+ messages in thread
From: David Woodhouse @ 2021-05-12  9:25 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Gabriel Krisman Bertazi
  Cc: Linux Doc Mailing List, Daniel W. S. Almeida, Jonathan Corbet,
	Arnd Bergmann, Borislav Petkov, David Howells,
	Greg Kroah-Hartman, James Morse, Kees Cook,
	Mauro Carvalho Chehab, Robert Richter, Thorsten Leemhuis,
	Tony Luck, keyrings, linux-edac, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Wed, 2021-05-12 at 10:44 +0200, Mauro Carvalho Chehab wrote:
> The main point here is that a large amount of those UTF-8 characters
> appeared as result of document conversion from DocBook/LaTeX/Markdown.
> 
> As the conversion ended, I don't expect the need of re-doing a series
> like that in the near future.
> 
> There are even some cases where the UTF-8 were doing wrong things, like
> using an EN DASH instead of an hyphen in order to pass a command line
> parameter, and the addition of non-printable BOM characters.
> 
> So, IMO, this is a necessarily cleanup after the conversion.

That part — fixing characters that are *wrong*, such as converting a
UTF-8 U+2014 EM DASH to a UTF-8 U+002D HYPHEN-MINUS, is reasonable
enough.

But you're not "avoiding using UTF-8 chars" there, as it says in the
title of this patch. HYPHEN-MINUS encoded as 0x2D *is* UTF-8.

I think you meant "avoid using non-ASCII chars", and even *that* is an
entirely bogus reason for doing anything at all, as discussed.

Limit yourself to fixing characters which are actually wrong, and it's
fine. One level of pointless trivia below spelling errors, mind you,
but at least not actively wrong.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

^ permalink raw reply	[flat|nested] 219+ messages in thread

* Re: [PATCH 06/53] docs: admin-guide: avoid using UTF-8 chars
  2021-05-12  9:25       ` David Woodhouse
@ 2021-05-12 10:22         ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 219+ messages in thread
From: Mauro Carvalho Chehab @ 2021-05-12 10:22 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Gabriel Krisman Bertazi, Linux Doc Mailing List,
	Daniel W. S. Almeida, Jonathan Corbet, Arnd Bergmann,
	Borislav Petkov, David Howells, Greg Kroah-Hartman, James Morse,
	Kees Cook, Mauro Carvalho Chehab, Robert Richter,
	Thorsten Leemhuis, Tony Luck, keyrings, linux-edac, linux-kernel

Em Wed, 12 May 2021 10:25:35 +0100
David Woodhouse <dwmw2@infradead.org> escreveu:

> On Wed, 2021-05-12 at 10:44 +0200, Mauro Carvalho Chehab wrote:
> > The main point here is that a large amount of those UTF-8 characters
> > appeared as result of document conversion from DocBook/LaTeX/Markdown.
> > 
> > As the conversion ended, I don't expect the need of re-doing a series
> > like that in the near future.
> > 
> > There are even some cases where the UTF-8 were doing wrong things, like
> > using an EN DASH instead of an hyphen in order to pass a command line
> > parameter, and the addition of non-printable BOM characters.
> > 
> > So, IMO, this is a necessarily cleanup after the conversion.  
> 
> That part — fixing characters that are *wrong*, such as converting a
> UTF-8 U+2014 EM DASH to a UTF-8 U+002D HYPHEN-MINUS, is reasonable
> enough.
> 
> But you're not "avoiding using UTF-8 chars" there, as it says in the
> title of this patch. HYPHEN-MINUS encoded as 0x2D *is* UTF-8.

Yeah, you're right, as ASCII is a subset of UTF-8 - as ASCII is
also subset of other charsets as well[1].

[1] ASCII is a subset for all charsets mentioned at:
       https://man7.org/linux/man-pages/man7/charsets.7.html

A more precise title would be something like:

	Use ASCII instead of non-ASCII UTF-8 alternate symbols
or
	Use ASCII subset instead of UTF-8 alternate symbols

See, the goal of this series is to address the cases where there are
multiple UTF-8 alternate symbols with the same meaning as the
original ASCII set. Most of them were introduced by tools like
DocBook/LaTeX/pandoc during document conversions[2], not by design,
but just because the UTF-8 non-ASCII symbols produce a nicer output 
in html or pdf. In another words, it was a toolset decision to change
them, diverging from what the author originally typed.

[2] I suspect that a few of them could have been introduced as a result
    of someone using a text editor like libreoffice (or equivalent),
    that has a similar behavior. 

With ReST, there's no need to use any those, as the building tools will
already do the such conversion when generating html/pdf output.

So, better to stick with ASCII subset on such cases, as it allows
to better use tools like grep and it makes easier to edit such files
on editors like vi, nano, emacs, etc.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 219+ messages in thread

end of thread, other threads:[~2021-05-12 14:45 UTC | newest]

Thread overview: 219+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-10 10:26 [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 01/53] docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 02/53] docs: ABI: remove a meaningless UTF-8 character Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 03/53] docs: ABI: remove some spurious characters Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 04/53] docs: index.rst: avoid using UTF-8 chars Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 05/53] docs: hwmon: " Mauro Carvalho Chehab
2021-05-10 13:30   ` Guenter Roeck
2021-05-10 10:26 ` [PATCH 06/53] docs: admin-guide: " Mauro Carvalho Chehab
2021-05-10 18:40   ` Gabriel Krisman Bertazi
2021-05-12  8:44     ` Mauro Carvalho Chehab
2021-05-12  9:25       ` David Woodhouse
2021-05-12 10:22         ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 07/53] docs: admin-guide: media: ipu3.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 08/53] docs: admin-guide: sysctl: kernel.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 09/53] docs: admin-guide: perf: imx-ddr.rst: " Mauro Carvalho Chehab
2021-05-10 10:26   ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 10/53] docs: admin-guide: pm: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: " Mauro Carvalho Chehab
2021-05-10 10:26   ` Mauro Carvalho Chehab
2021-05-10 19:28   ` Mathieu Poirier
2021-05-10 19:28     ` Mathieu Poirier
2021-05-10 10:26 ` [PATCH 12/53] docs: driver-api: " Mauro Carvalho Chehab
     [not found]   ` <CAHp75Vegsb-+fVppv3C7Jp0a=mEGAh2pchX=Cr5ZvOMFt+G73Q@mail.gmail.com>
2021-05-12  8:49     ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 13/53] docs: driver-api: fpga: " Mauro Carvalho Chehab
2021-05-10 17:48   ` Moritz Fischer
2021-05-10 10:26 ` [PATCH 14/53] docs: driver-api: iio: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 15/53] docs: driver-api: thermal: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 16/53] docs: driver-api: media: drivers: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 17/53] docs: driver-api: firmware: other_interfaces.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 18/53] docs: driver-api: nvdimm: btt.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 19/53] docs: fault-injection: nvme-fault-injection.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 20/53] docs: usb: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 21/53] docs: process: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 22/53] docs: block: data-integrity.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 23/53] docs: userspace-api: media: fdl-appendix.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 24/53] docs: userspace-api: media: v4l: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 25/53] docs: userspace-api: media: dvb: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 26/53] docs: vm: zswap.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 27/53] docs: filesystems: f2fs.rst: " Mauro Carvalho Chehab
2021-05-10 10:26   ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-11  3:16   ` Chao Yu
2021-05-11  3:16     ` Chao Yu
2021-05-10 10:26 ` [PATCH 28/53] docs: filesystems: ext4: " Mauro Carvalho Chehab
2021-05-10 19:23   ` Theodore Ts'o
2021-05-10 10:26 ` [PATCH 29/53] docs: kernel-hacking: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 30/53] docs: hid: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 31/53] docs: security: tpm: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 32/53] docs: security: keys: trusted-encrypted.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 33/53] docs: riscv: vm-layout.rst: " Mauro Carvalho Chehab
2021-05-10 10:26   ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 34/53] docs: networking: scaling.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 35/53] docs: networking: devlink: devlink-dpipe.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 36/53] docs: networking: device_drivers: " Mauro Carvalho Chehab
2021-05-10 10:26   ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 37/53] docs: x86: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 38/53] docs: scheduler: sched-deadline.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 39/53] docs: dev-tools: testing-overview.rst: " Mauro Carvalho Chehab
2021-05-10 10:48   ` Marco Elver
2021-05-12  8:52     ` Mauro Carvalho Chehab
2021-05-10 23:35   ` David Gow
2021-05-12  8:14     ` Mauro Carvalho Chehab
2021-05-12  8:29     ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 40/53] docs: power: powercap: powercap.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 41/53] docs: ABI: " Mauro Carvalho Chehab
2021-05-10 13:53   ` Guenter Roeck
2021-05-10 10:26 ` [PATCH 42/53] docs: doc-guide: contributing.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 43/53] docs: PCI: acpi-info.rst: " Mauro Carvalho Chehab
2021-05-10 10:37   ` Krzysztof Wilczyński
2021-05-10 10:26 ` [PATCH 44/53] docs: gpu: " Mauro Carvalho Chehab
2021-05-10 10:26   ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 10:26   ` Mauro Carvalho Chehab
2021-05-10 11:16   ` Jani Nikula
2021-05-10 11:16     ` [Intel-gfx] " Jani Nikula
2021-05-10 11:16     ` Jani Nikula
2021-05-10 12:36   ` Liviu Dudau
2021-05-10 12:36     ` [Intel-gfx] " Liviu Dudau
2021-05-10 12:36     ` Liviu Dudau
2021-05-10 10:26 ` [PATCH 45/53] docs: sound: kernel-api: writing-an-alsa-driver.rst: " Mauro Carvalho Chehab
2021-05-10 10:26   ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 46/53] docs: arm64: arm-acpi.rst: " Mauro Carvalho Chehab
2021-05-10 10:26   ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 47/53] docs: infiniband: tag_matching.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 48/53] docs: timers: no_hz.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 49/53] docs: misc-devices: ibmvmc.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 50/53] docs: firmware-guide: acpi: lpit.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 51/53] docs: firmware-guide: acpi: dsd: graph.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 52/53] docs: virt: kvm: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 53/53] docs: RCU: " Mauro Carvalho Chehab
2021-05-11  0:05   ` Paul E. McKenney
2021-05-10 10:52 ` [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII Thorsten Leemhuis
2021-05-10 10:52   ` [Intel-wired-lan] " Thorsten Leemhuis
2021-05-10 10:52   ` [Intel-gfx] " Thorsten Leemhuis
2021-05-10 10:52   ` Thorsten Leemhuis
2021-05-10 10:52   ` Thorsten Leemhuis
2021-05-10 10:52   ` [f2fs-dev] " Thorsten Leemhuis
2021-05-10 10:52   ` Thorsten Leemhuis
2021-05-10 11:19   ` Mauro Carvalho Chehab
2021-05-10 11:19     ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 11:19     ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 11:19     ` Mauro Carvalho Chehab
2021-05-10 11:19     ` Mauro Carvalho Chehab
2021-05-10 11:19     ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 11:19     ` Mauro Carvalho Chehab
2021-05-10 12:27     ` Mauro Carvalho Chehab
2021-05-10 12:27       ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 12:27       ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 12:27       ` Mauro Carvalho Chehab
2021-05-10 12:27       ` Mauro Carvalho Chehab
2021-05-10 12:27       ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 12:27       ` Mauro Carvalho Chehab
2021-05-10 10:54 ` David Woodhouse
2021-05-10 10:54   ` [Intel-wired-lan] " David Woodhouse
2021-05-10 10:54   ` [Intel-gfx] " David Woodhouse
2021-05-10 10:54   ` David Woodhouse
2021-05-10 10:54   ` David Woodhouse
2021-05-10 10:54   ` David Woodhouse
2021-05-10 11:55   ` Mauro Carvalho Chehab
2021-05-10 11:55     ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 11:55     ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 11:55     ` Mauro Carvalho Chehab
2021-05-10 11:55     ` Mauro Carvalho Chehab
2021-05-10 11:55     ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 11:55     ` Mauro Carvalho Chehab
2021-05-10 12:29     ` [f2fs-dev] " beroal
2021-05-10 13:16     ` Edward Cree
2021-05-10 13:16       ` [Intel-wired-lan] " Edward Cree
2021-05-10 13:16       ` [Intel-gfx] " Edward Cree
2021-05-10 13:16       ` Edward Cree
2021-05-10 13:16       ` Edward Cree
2021-05-10 13:16       ` [f2fs-dev] " Edward Cree
2021-05-10 13:16       ` Edward Cree
2021-05-10 13:38       ` Mauro Carvalho Chehab
2021-05-10 13:38         ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 13:38         ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 13:38         ` Mauro Carvalho Chehab
2021-05-10 13:38         ` Mauro Carvalho Chehab
2021-05-10 13:38         ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 13:38         ` Mauro Carvalho Chehab
2021-05-10 13:58         ` Edward Cree
2021-05-10 13:58           ` [Intel-wired-lan] " Edward Cree
2021-05-10 13:58           ` [Intel-gfx] " Edward Cree
2021-05-10 13:58           ` Edward Cree
2021-05-10 13:58           ` Edward Cree
2021-05-10 13:58           ` [f2fs-dev] " Edward Cree
2021-05-10 13:58           ` Edward Cree
2021-05-10 13:59       ` Matthew Wilcox
2021-05-10 13:59         ` [Intel-wired-lan] " Matthew Wilcox
2021-05-10 13:59         ` [Intel-gfx] " Matthew Wilcox
2021-05-10 13:59         ` Matthew Wilcox
2021-05-10 13:59         ` Matthew Wilcox
2021-05-10 13:59         ` [f2fs-dev] " Matthew Wilcox
2021-05-10 13:59         ` Matthew Wilcox
2021-05-10 14:33         ` Edward Cree
2021-05-10 14:33           ` [Intel-wired-lan] " Edward Cree
2021-05-10 14:33           ` [Intel-gfx] " Edward Cree
2021-05-10 14:33           ` Edward Cree
2021-05-10 14:33           ` Edward Cree
2021-05-10 14:33           ` [f2fs-dev] " Edward Cree
2021-05-10 14:33           ` Edward Cree
2021-05-11  9:00           ` Mauro Carvalho Chehab
2021-05-11  9:00             ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-11  9:00             ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-11  9:00             ` Mauro Carvalho Chehab
2021-05-11  9:00             ` Mauro Carvalho Chehab
2021-05-11  9:00             ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-11  9:00             ` Mauro Carvalho Chehab
2021-05-11  9:19             ` David Woodhouse
2021-05-11  9:19               ` [Intel-wired-lan] " David Woodhouse
2021-05-11  9:19               ` [Intel-gfx] " David Woodhouse
2021-05-11  9:19               ` David Woodhouse
2021-05-11  9:19               ` David Woodhouse
2021-05-11  9:19               ` David Woodhouse
2021-05-10 13:49     ` David Woodhouse
2021-05-10 13:49       ` [Intel-wired-lan] " David Woodhouse
2021-05-10 13:49       ` [Intel-gfx] " David Woodhouse
2021-05-10 13:49       ` David Woodhouse
2021-05-10 13:49       ` David Woodhouse
2021-05-10 13:49       ` David Woodhouse
2021-05-10 19:22       ` Theodore Ts'o
2021-05-10 19:22         ` [Intel-wired-lan] " Theodore Ts'o
2021-05-10 19:22         ` [Intel-gfx] " Theodore Ts'o
2021-05-10 19:22         ` Theodore Ts'o
2021-05-10 19:22         ` Theodore Ts'o
2021-05-10 19:22         ` [f2fs-dev] " Theodore Ts'o
2021-05-10 19:22         ` Theodore Ts'o
2021-05-11  9:37         ` Mauro Carvalho Chehab
2021-05-11  9:37           ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-11  9:37           ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-11  9:37           ` Mauro Carvalho Chehab
2021-05-11  9:37           ` Mauro Carvalho Chehab
2021-05-11  9:37           ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-11  9:37           ` Mauro Carvalho Chehab
2021-05-11  9:25       ` Mauro Carvalho Chehab
2021-05-11  9:25         ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-11  9:25         ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-11  9:25         ` Mauro Carvalho Chehab
2021-05-11  9:25         ` Mauro Carvalho Chehab
2021-05-11  9:25         ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-11  9:25         ` Mauro Carvalho Chehab
2021-05-10 14:00     ` Ben Boeckel
2021-05-10 14:00       ` [Intel-wired-lan] " Ben Boeckel
2021-05-10 14:00       ` [Intel-gfx] " Ben Boeckel
2021-05-10 14:00       ` Ben Boeckel
2021-05-10 14:00       ` Ben Boeckel
2021-05-10 14:00       ` [f2fs-dev] " Ben Boeckel
2021-05-10 14:00       ` Ben Boeckel
2021-05-10 21:57 ` Adam Borowski
2021-05-10 21:57   ` [Intel-wired-lan] " Adam Borowski
2021-05-10 21:57   ` [Intel-gfx] " Adam Borowski
2021-05-10 21:57   ` Adam Borowski
2021-05-10 21:57   ` Adam Borowski
2021-05-10 21:57   ` [f2fs-dev] " Adam Borowski
2021-05-10 21:57   ` Adam Borowski

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.