Re: [PATCH v4 03/10] i3c: Add sysfs ABI spec

[Geert Uytterhoeven]

Hi Greg,

On Wed, May 2, 2018 at 1:10 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Wed, May 02, 2018 at 11:47:49AM +0200, Geert Uytterhoeven wrote:
>> On Sun, Apr 29, 2018 at 3:37 PM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote:
>> >> Document sysfs files/directories/symlinks exposed by the I3C subsystem.
>> >>
>> >> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
>> >> ---
>> >> Changes in v2:
>> >> - new patch
>> >> ---
>> >>  Documentation/ABI/testing/sysfs-bus-i3c | 95 
>> >> +
>> >>  1 file changed, 95 insertions(+)
>> >>  create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
>> >>
>> >> diff --git a/Documentation/ABI/testing/sysfs-bus-i3c 
>> >> b/Documentation/ABI/testing/sysfs-bus-i3c
>> >> new file mode 100644
>> >> index ..5e88cc093e0e
>> >> --- /dev/null
>> >> +++ b/Documentation/ABI/testing/sysfs-bus-i3c
>> >> @@ -0,0 +1,95 @@
>> >> +What:/sys/bus/i3c/devices/i3c-
>> >> +KernelVersion:  4.16
>> >
>> > Wrong kernel versions :)
>>
>> Do you update these when backporting to stable? ;-)
>
> I'm not adding new features/subsystems to stable :)

True. So let's leave that for the LTSI patch monkey ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 03/10] i3c: Add sysfs ABI spec

[Geert Uytterhoeven]

Hi Greg,

On Sun, Apr 29, 2018 at 3:37 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote:
>> Document sysfs files/directories/symlinks exposed by the I3C subsystem.
>>
>> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
>> ---
>> Changes in v2:
>> - new patch
>> ---
>>  Documentation/ABI/testing/sysfs-bus-i3c | 95 
>> +
>>  1 file changed, 95 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-i3c 
>> b/Documentation/ABI/testing/sysfs-bus-i3c
>> new file mode 100644
>> index ..5e88cc093e0e
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-i3c
>> @@ -0,0 +1,95 @@
>> +What:/sys/bus/i3c/devices/i3c-
>> +KernelVersion:  4.16
>
> Wrong kernel versions :)

Do you update these when backporting to stable? ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander

[Geert Uytterhoeven]

Hi Boris,

On Mon, Mar 26, 2018 at 1:25 PM, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> On Mon, 26 Mar 2018 12:12:54 +0200
> Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>> On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
>> <boris.brezil...@bootlin.com> wrote:
>> > Document the Cadence I3C gpio expander bindings.
>> >
>> > Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
>>
>> Thanks for your patch!
>>
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
>>
>> > +- #interrupt-cells : Should be 2.  The first cell is the GPIO number.
>> > +  The second cell bits[3:0] is used to specify trigger type and level 
>> > flags:
>> > +  1 = low-to-high edge triggered.
>> > +  2 = high-to-low edge triggered.
>> > +  3 = triggered on both edges.
>> > +  4 = active high level-sensitive.
>> > +  8 = active low level-sensitive.
>>
>> These are identical to the values in 
>> .
>> Perhaps you can refer to those definitions?
>
> Well, I'm not sure this is allowed since DT bindings docs are
> supposed to be OS-agnostic and macros defined in
>  are, AFAIK, only available to
> Linux.

If they're under include/dt-bindings/, they're part of the DT bindings.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings

[Geert Uytterhoeven]

Hi Boris,

On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> From: Boris Brezillon <boris.brezil...@free-electrons.com>
>
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,140 @@

> +I3C devices
> +===
> +
> +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> +are thus discoverable. So, by default, I3C devices do not have to be 
> described
> +in the device tree.

But if they're described, they should have a compatible value, no?

> +This being said, one might want to attach extra resources to these devices,
> +and those resources may have to be described in the device tree, which in 
> turn
> +means we have to describe I3C devices.
> +
> +Another use case for describing an I3C device in the device tree is when this
> +I3C device has a static address and we want to assign it a specific dynamic
> +address before the DAA takes place (so that other devices on the bus can't
> +take this dynamic address).
> +
> +The I3C device should be names @,,

named

So the i3c-pid in the unit address is represented as a 64-bit number, not as two
comma-separated 32-bit numbers?

> +Example:
> +
> +   i3c-master@d04 {
> +   compatible = "cdns,i3c-master";
> +   clocks = <>, <>;
> +   clock-names = "pclk", "sysclk";
> +   interrupts = <3 0>;
> +   reg = <0x0d04 0x1000>;
> +   #address-cells = <3>;
> +   #size-cells = <0>;
> +
> +   status = "okay";
> +   i2c-scl-frequency = <10>;
> +
> +   /* I2C device. */
> +   nunchuk: nunchuk@52 {

@52,8010?

> +   compatible = "nintendo,nunchuk";
> +   reg = <0x52 0x8010 0x0>;
> +   };
> +
> +   /* I3C device with a static address. */
> +   thermal_sensor: sensor@68,39200144004 {

No compatible value?

> +   reg = <0x68 0x392 0x144004>;
> +   assigned-address = <0xa>;
> +   };
> +
> +   /*
> +* I3C device without a static address but requiring resources
> +* described in the DT.
> +*/
> +   sensor@0,39200154004 {

No compatible value?

> +   reg = <0x0 0x392 0x154004>;
> +   clocks = <_provider 0>;
> +   };
> +   };

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander

[Geert Uytterhoeven]

Hi Boris,

On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> Document the Cadence I3C gpio expander bindings.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
> @@ -0,0 +1,38 @@
> +* Cadence I3C GPIO expander
> +
> +The Cadence I3C GPIO expander provides 8 GPIOs controllable over I3C.
> +This GPIOs can be configured in output or input mode and if they are in input
> +mode they can generate IBIs (In Band Interrupts).
> +
> +Required properties for GPIO node:
> +- reg : 3 cells encoding the I3C static address (none in our case) and the 
> I3C
> +   Provisional ID. See Documentation/devicetree/bindings/i3c/i3c.txt for
> +   more details.
> +   Should be <0x0 0x392 0x0>.

No compatible value?

> +- gpio-controller : Marks the device node as a gpio controller.
> +- #gpio-cells : Should be two. The first cell is the pin number and
> +  the second cell is used to specify the gpio polarity:
> +  0 = active high
> +  1 = active low
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- #interrupt-cells : Should be 2.  The first cell is the GPIO number.
> +  The second cell bits[3:0] is used to specify trigger type and level flags:
> +  1 = low-to-high edge triggered.
> +  2 = high-to-low edge triggered.
> +  3 = triggered on both edges.
> +  4 = active high level-sensitive.
> +  8 = active low level-sensitive.
> +
> +Example:
> +
> +   i3c-master@xxx {
> +   ...
> +   i3c_gpio_expander: gpio@0,1c9,0 {

gpio@0,392,0?

> +   reg = <0 0x392 0x0>;
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +   interrupt-controller;
> +       #interrupt-cells = <2>;
> +   };
> +   ...
> +   };

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander

[Geert Uytterhoeven]

Hi Boris,

On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> Document the Cadence I3C gpio expander bindings.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt

> +- #interrupt-cells : Should be 2.  The first cell is the GPIO number.
> +  The second cell bits[3:0] is used to specify trigger type and level flags:
> +  1 = low-to-high edge triggered.
> +  2 = high-to-low edge triggered.
> +  3 = triggered on both edges.
> +  4 = active high level-sensitive.
> +  8 = active low level-sensitive.

These are identical to the values in .
Perhaps you can refer to those definitions?
I don't think we want to see the hardcoded numbers in DTS files.

Gr{oetje,eeting}s,

    Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/16] remove eight obsolete architectures

[Geert Uytterhoeven]

Hi David,

On Thu, Mar 15, 2018 at 10:42 AM, David Howells <dhowe...@redhat.com> wrote:
> Do we have anything left that still implements NOMMU?

Sure: arm, c6x, m68k, microblaze, and  sh.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings

[Geert Uytterhoeven]

Hi Boris,

On Thu, Dec 14, 2017 at 4:16 PM, Boris Brezillon
<boris.brezil...@free-electrons.com> wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,128 @@
> +Generic device tree bindings for I3C busses
> +===
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +---
> +
> +- #address-cells  - should be <1>. Read more about addresses below.
> +- #size-cells - should be <0>.
> +- compatible  - name of I3C bus controller following generic names
> +   recommended practice.
> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +---
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> +transfers. When undefined the core set it to 12.5MHz.

sets

> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> +transfers. When undefined, the core looks at LVR values

LVR (Legacy I2C Virtual Register)

> +of I2C devices described in the device tree to determine
> +the maximum I2C frequency.
> +
> +I2C devices
> +===
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:

This colon looks a bit funny here, as below is a sentence, not a list.

> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.

Perhaps rewrite as:

  Each I2C device connected to the bus should be described in a subnode with
  properties.  All properties described in
  Documentation/devicetree/bindings/i2c/i2c.txt are valid here, but several
  new properties have been added.

> +
> +New required properties:
> +
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
> +  describing device capabilities as described in the I3C
> +  specification.
> +
> +  bit[31:8]: unused
> +  bit[7:5]: I2C device index. Possible values
> +   * 0: I2C device has a 50 ns spike filter
> +   * 1: I2C device does not have a 50 ns spike filter but supports 
> high
> +frequency on SCL
> +   * 2: I2C device does not have a 50 ns spike filter and is not
> +tolerant to high frequencies
> +   * 3-7: reserved
> +
> +  bit[4]: tell whether the device operates in FM or FM+ mode
> +   * 0: FM+ mode
> +   * 1: FM mode

As this is the only reference to "FM", perhaps clarify the acronym, like you
do for DAA below.

> +
> +  bit[3:0]: device type
> +   * 0-15: reserved
> +
> +I3C devices
> +===
> +
> +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> +are thus discoverable. So, by default, I3C devices do not have to be 
> described
> +in the device tree.
> +This being said, one might want to attach extra resources to these devices,
> +and those resources may have to be described in the device tree, which in 
> turn
> +means we have to describe I3C devices.
> +
> +Another use case for describing an I3C device in the device tree is when this
> +I3C device has a static address and we want to assign it a specific dynamic
> +address before the DAA takes place (so that other devices on the bus can't
> +take this dynamic address).
> +
> +Required properties
> +---
> +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> +  device discovered during DAA with its device tree definition. The
> +  PID is supposed to be unique on a given bus, which guarantees a 1:1
> +  match. This property becomes optional if a reg property is defined,
> +  meaning that the device has a static address.
> +
> +Optional properties
> +---
> +- reg: static address. Only valid is the device has a static address.

if


-- 
Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of

Re: [PATCH] documentation: update list of available compiled-in fonts

[Geert Uytterhoeven]

Hi Randy,

On Tue, Nov 7, 2017 at 5:48 AM, Randy Dunlap <rdun...@infradead.org> wrote:
> From: Randy Dunlap <rdun...@infradead.org>
>
> Update list of available compiled-in fonts in lib/fonts/:
> add 6x10 and drop RomanLarge (which was reverted 12 years ago).
>
> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> Cc: Geert Uytterhoeven <ge...@linux-m68k.org>

Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>

> --- lnx-414-rc8.orig/Documentation/fb/fbcon.txt
> +++ lnx-414-rc8/Documentation/fb/fbcon.txt
> @@ -77,8 +77,8 @@ C. Boot options
>  1. fbcon=font:
>
>  Select the initial font to use. The value 'name' can be any of the
> -compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge,
> -SUN8x16, SUN12x22, ProFont6x11, Acorn8x8, PEARL8x8.
> +compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6,
> +SUN8x16, SUN12x22, 6x10, ProFont6x11, Acorn8x8, PEARL8x8.

While at it, perhaps you want to sort the list alphabetically?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] device: Fix link to device power management documentation

[Geert Uytterhoeven]

Correct location as of commit 2728b2d2e5be4b82 ("PM / core / docs:
Convert sleep states API document to reST").

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
Note that the link was already broken before...
---
 include/linux/device.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index beabdbc0842059b3..9db9c528bb5d1608 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -838,7 +838,7 @@ struct dev_links_info {
  * @driver_data: Private pointer for driver specific info.
  * @links: Links to suppliers and consumers of this device.
  * @power: For device power management.
- * See Documentation/power/admin-guide/devices.rst for details.
+ * See Documentation/driver-api/pm/devices.rst for details.
  * @pm_domain: Provide callbacks that are executed during system suspend,
  * hibernation, system resume and during runtime PM transitions
  * along with subsystem-level and driver-level callbacks.
-- 
2.7.4

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

Re: [RFC 2/5] i3c: Add core I3C infrastructure

[Geert Uytterhoeven]

On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang <w...@the-dreams.de> wrote:
>> I'm perfectly fine with the I3C / I2C framework separation. The only
>> minor problem I had with that was the inaccuracy of the
>> sysfs/device-model representation: we don't have one i2c and one i3c
>> bus, we just have one i3c bus with a mix of i2c and i3c devices.
>
> I understand that. What if I2C had the same seperation between the "bus"
> and the "master"?

There can be multiple masters on an i2c bus.  But not on an i3c bus, due
to SCL being push/pull.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH resend] Documentation: arm: Replace use of virt_to_phys with __pa_symbol

[Geert Uytterhoeven]

Hi Russell,

On Mon, Jul 17, 2017 at 11:20 PM, Russell King - ARM Linux
<li...@armlinux.org.uk> wrote:
> On Mon, Jul 17, 2017 at 01:44:45PM -0600, Jonathan Corbet wrote:
>> On Mon, 17 Jul 2017 15:39:28 +0200
>> Geert Uytterhoeven <geert+rene...@glider.be> wrote:
>>
>> > All low-level PM/SMP code using virt_to_phys() should actually use
>> > __pa_symbol() against kernel symbols.  Update the documentation to move
>> > away from virt_to_phys().
>> >
>> > Cfr. commit 6996cbb2372189f7 ("ARM: 8641/1: treewide: Replace uses of
>> > virt_to_phys with __pa_symbol")
>>
>> I was kind of hoping for an ack from somebody on this, but, four months
>> later, I'll take the absence of complaints as being enough.  Applied,
>> thanks.
>
> Maybe those who contributed Documentation/arm/firmware.txt should
> have responded, seems that was Tomasz Figa <t.f...@samsung.com>
> who isn't even on the Cc list for this...

Ah, get_maintainer.pl didn't report Tomasz' Samsung email address, which
bounces for sure ;-)

> Can't blame people who aren't copied with the patch for not
> responding.

I did copy the people responsible for the __pa_symbol conversion.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH resend] Documentation: arm: Replace use of virt_to_phys with __pa_symbol

[Geert Uytterhoeven]

All low-level PM/SMP code using virt_to_phys() should actually use
__pa_symbol() against kernel symbols.  Update the documentation to move
away from virt_to_phys().

Cfr. commit 6996cbb2372189f7 ("ARM: 8641/1: treewide: Replace uses of
virt_to_phys with __pa_symbol")

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/arm/firmware.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm/firmware.txt b/Documentation/arm/firmware.txt
index da6713adac8acffc..7f175dbb427e631a 100644
--- a/Documentation/arm/firmware.txt
+++ b/Documentation/arm/firmware.txt
@@ -60,7 +60,7 @@ Example of using a firmware operation:
 
/* some platform code, e.g. SMP initialization */
 
-   __raw_writel(virt_to_phys(exynos4_secondary_startup),
+   __raw_writel(__pa_symbol(exynos4_secondary_startup),
CPU1_BOOT_REG);
 
/* Call Exynos specific smc call */
-- 
2.7.4

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

Re: [PATCH v2 25/26] zorro.txt: standardize document format

[Geert Uytterhoeven]

On Sat, Jun 17, 2017 at 5:27 PM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - Use right marks for titles;
> - Use authorship marks;
> - Mark literals and literal blocks;
> - Use autonumbered list for references.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Acked-by: Geert Uytterhoeven <ge...@linux-m68k.org>

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/17] Documentation: atomic_ops.txt is core-api/atomic_ops.rst

[Geert Uytterhoeven]

CC doc folks

On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt  wrote:
> I was reading the memory barries documentation in order to make sure the
> RISC-V barries were correct, and I found a broken link to the atomic
> operations documentation.
>
> Signed-off-by: Palmer Dabbelt 
> ---
>  Documentation/memory-barriers.txt | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index 732f10ea382e..f1c9eaa45a57 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -498,11 +498,11 @@ And a couple of implicit varieties:
>   This means that ACQUIRE acts as a minimal "acquire" operation and
>   RELEASE acts as a minimal "release" operation.
>
> -A subset of the atomic operations described in atomic_ops.txt have ACQUIRE
> -and RELEASE variants in addition to fully-ordered and relaxed (no barrier
> -semantics) definitions.  For compound atomics performing both a load and a
> -store, ACQUIRE semantics apply only to the load and RELEASE semantics apply
> -only to the store portion of the operation.
> +A subset of the atomic operations described in core-api/atomic_ops.rst have
> +ACQUIRE and RELEASE variants in addition to fully-ordered and relaxed (no
> +barrier semantics) definitions.  For compound atomics performing both a load
> +and a store, ACQUIRE semantics apply only to the load and RELEASE semantics
> +apply only to the store portion of the operation.
>
>  Memory barriers are only required where there's a possibility of interaction
>  between two CPUs or between a CPU and a device.  If it can be guaranteed that
> --
> 2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/29] pinctrl.txt: standardize document format

[Geert Uytterhoeven]

Hi Mauro,

On Fri, May 19, 2017 at 3:25 AM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx.
>
> This document is almost following the standard stile.
>
> There are only two things to adjust on it:
>
> - promote the level of the document title;
> - mark literal blocks as such.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Thanks for your patch!

> --- a/Documentation/pinctrl.txt
> +++ b/Documentation/pinctrl.txt
> @@ -1,4 +1,7 @@
> +===
>  PINCTRL (PIN CONTROL) subsystem
> +===
> +
>  This document outlines the pin control subsystem in Linux
>
>  This subsystem deals with:
> @@ -33,7 +36,7 @@ When a PIN CONTROLLER is instantiated, it will register a 
> descriptor to the
>  pin control framework, and this descriptor contains an array of pin 
> descriptors
>  describing the pins handled by this specific pin controller.
>
> -Here is an example of a PGA (Pin Grid Array) chip seen from underneath:
> +Here is an example of a PGA (Pin Grid Array) chip seen from underneath::
>
>  A   B   C   D   E   F   G   H
>
> @@ -54,39 +57,40 @@ Here is an example of a PGA (Pin Grid Array) chip seen 
> from underneath:
> 1o   o   o   o   o   o   o   o
>
>  To register a pin controller and name all the pins on this package we can do
> -this in our driver:
> +this in our driver::
>
> -#include 
> +   #include 
>
> -const struct pinctrl_pin_desc foo_pins[] = {
> -  PINCTRL_PIN(0, "A8"),
> -  PINCTRL_PIN(1, "B8"),
> -  PINCTRL_PIN(2, "C8"),
> -  ...
> -  PINCTRL_PIN(61, "F1"),
> -  PINCTRL_PIN(62, "G1"),
> -  PINCTRL_PIN(63, "H1"),
> -};
> +   const struct pinctrl_pin_desc foo_pins[] = {
> +   PINCTRL_PIN(0, "A8"),
> +   PINCTRL_PIN(1, "B8"),
> +   PINCTRL_PIN(2, "C8"),
> +   ...
> +   PINCTRL_PIN(61, "F1"),
> +   PINCTRL_PIN(62, "G1"),
> +   PINCTRL_PIN(63, "H1"),
> +   };

The above block is no longer indented correctly.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: arm: Replace use of virt_to_phys with __pa_symbol

[Geert Uytterhoeven]

All low-level PM/SMP code using virt_to_phys() should actually use
__pa_symbol() against kernel symbols.  Update the documentation to move
away from virt_to_phys().

Cfr. commit 6996cbb2372189f7 ("ARM: 8641/1: treewide: Replace uses of
virt_to_phys with __pa_symbol")

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/arm/firmware.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm/firmware.txt b/Documentation/arm/firmware.txt
index da6713adac8acffc..7f175dbb427e631a 100644
--- a/Documentation/arm/firmware.txt
+++ b/Documentation/arm/firmware.txt
@@ -60,7 +60,7 @@ Example of using a firmware operation:
 
/* some platform code, e.g. SMP initialization */
 
-   __raw_writel(virt_to_phys(exynos4_secondary_startup),
+   __raw_writel(__pa_symbol(exynos4_secondary_startup),
CPU1_BOOT_REG);
 
/* Call Exynos specific smc call */
-- 
2.7.4

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

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Geert Uytterhoeven]

Hi Mauro,
On Mon, Jan 23, 2017 at 2:01 PM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> Em Mon, 23 Jan 2017 11:44:54 +0100
> Geert Uytterhoeven <ge...@linux-m68k.org> escreveu:
>> On Mon, Jan 23, 2017 at 11:34 AM, Mauro Carvalho Chehab
>> <mche...@s-opensource.com> wrote:
>> > Em Fri, 13 Jan 2017 12:03:24 -0800
>> > Joe Perches <j...@perches.com> escreveu:
>> >> On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
>> >> > On Tue, 10 Jan 2017 14:09:51 -0800
>> >> > Joe Perches <j...@perches.com> wrote:
>> >> >
>> >> > > Make these files symlinks to the .rst equivalents
>> >> >
>> >> > So I am not necessarily opposed to doing this, but the changelog lacks
>> >> > one important thing: why do we need to make that change?  Have the
>> >> > existing one-liner files been a problem somehow?
>> >>
>> >> The files tell people to open other files.
>> >>
>> >> Giving the old link to people just tells them to
>> >> use the new filename instead.
>> >>
>> >> symlinks open the new file automatically.
>> >>
>> >> $ head Documentation/CodingStyle
>> >> This file has moved to process/coding-style.rst
>> >>
>> >> vs a symlink
>> >>
>> >> $ head Documentation/CodingStyle
>> >> .. _codingstyle:
>> >>
>> >> Linux kernel coding style
>> >> =
>> >>
>> >> This is a short document describing the preferred coding style for the
>> >> linux kernel.  Coding style is very personal, and I won't **force** my
>> >> views on anybody, but this is what goes for anything that I have to be
>> >> able to maintain, and I'd prefer it for most other things too.  Please
>> >> at least consider the points made here.
>> >
>> > IMHO, we should either use symlinks or files with "replaced by" contents.
>> >
>> > The main difference between a "pointer file" and a symlink is that the
>> > first indicates a temporary solution, teaching people that the
>> > file got renamed and were it is located now. As such, we can remove
>> > those "pointer files" on some future Kernel releases without much concern.
>> >
>> > A symlink indicates a more permanent situation, as people will keep
>> > using the symlinked files as before. That means that any attempt to
>> > remove those in the future will generate concerns.
>>
>> Agreed, about temporary vs. permanent.
>>
>> > So, I'm in favor of using the "pointer files" instead, as it
>> > gives us an easier way to get rid of them when we find convenient.
>>
>> When will/can we get rid of them?
>
> That's a good question.
>
>> Old (doh) kernels, and new versions of stable kernels will keep on having
>> them for the next +10 years.
>
> Old Kernels used to have a separate directory for x86 32 and 64
> bits archs. That didn't prevent us to merge them on an unified x86
> architecture.

Sure, but the Internet isn't filled with links pointing newbies to random
old platform-specific source files.

>> To me, these[*] filenames are more like a user-visible API,
>
> Don't agree with it ;) From time to time, we change filenames as
> needed.
>
>> which should
>> not be changed without given consideration.
>
>>
>> [*] CodingStyle and SubmittingPatches (there may be others) are linked from
>> many web pages and email archives.
>> Anyone looked at how many links Google thinks there are?
>
> I've no idea. I suspect that there won't be that many hiperlinks
> pointing to some URL that contains CodingStyle/SubmittingPatches, but I
> may be wrong.
>
> It should be said that, due to strong reasons, we broke all URL links to the
> Kernel trees in 2011, as the kernel.org git trees were disabled, upstream
> moved to github. The upstream tree was also renamed once, also in 2011,
> from linux-2.6.git to linux.git (although a symlink still exists).
>
> That helps us to track how many times it takes for people to update
> their URLs to keep track to upstream changes.
>
> With that in mind, there are only 4 places using the old URL:
>
> https://www.google.com.br/search?q=http://git.kernel.org/%3Fp%3Dlinux/kernel/git/torvalds/linux-2.6.git%3Ba%3Dblob%3Bf%3DDocumentation/SubmittingPatches=utf-8=utf-8_rd=cr=VvyFWK3wJ4nHwASOmL-IAw#q=%22http:%2F%2Fgit.kernel.org%2F%3Fp%3Dlinux%2Fkernel%2Fgit%2Ftorvalds%

Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

[Geert Uytterhoeven]

Hi Mauro,

On Mon, Jan 23, 2017 at 11:34 AM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> Em Fri, 13 Jan 2017 12:03:24 -0800
> Joe Perches <j...@perches.com> escreveu:
>> On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
>> > On Tue, 10 Jan 2017 14:09:51 -0800
>> > Joe Perches <j...@perches.com> wrote:
>> >
>> > > Make these files symlinks to the .rst equivalents
>> >
>> > So I am not necessarily opposed to doing this, but the changelog lacks
>> > one important thing: why do we need to make that change?  Have the
>> > existing one-liner files been a problem somehow?
>>
>> The files tell people to open other files.
>>
>> Giving the old link to people just tells them to
>> use the new filename instead.
>>
>> symlinks open the new file automatically.
>>
>> $ head Documentation/CodingStyle
>> This file has moved to process/coding-style.rst
>>
>> vs a symlink
>>
>> $ head Documentation/CodingStyle
>> .. _codingstyle:
>>
>> Linux kernel coding style
>> =
>>
>> This is a short document describing the preferred coding style for the
>> linux kernel.  Coding style is very personal, and I won't **force** my
>> views on anybody, but this is what goes for anything that I have to be
>> able to maintain, and I'd prefer it for most other things too.  Please
>> at least consider the points made here.
>
> IMHO, we should either use symlinks or files with "replaced by" contents.
>
> The main difference between a "pointer file" and a symlink is that the
> first indicates a temporary solution, teaching people that the
> file got renamed and were it is located now. As such, we can remove
> those "pointer files" on some future Kernel releases without much concern.
>
> A symlink indicates a more permanent situation, as people will keep
> using the symlinked files as before. That means that any attempt to
> remove those in the future will generate concerns.

Agreed, about temporary vs. permanent.

> So, I'm in favor of using the "pointer files" instead, as it
> gives us an easier way to get rid of them when we find convenient.

When will/can we get rid of them?
Old (doh) kernels, and new versions of stable kernels will keep on having
them for the next +10 years.

To me, these[*] filenames are more like a user-visible API, which should
not be changed without given consideration.

[*] CodingStyle and SubmittingPatches (there may be others) are linked from
many web pages and email archives.
Anyone looked at how many links Google thinks there are?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] Documentation changes for 4.10

[Geert Uytterhoeven]

Hi Jon, Jani,

On Sun, Dec 11, 2016 at 11:00 PM, Jonathan Corbet <cor...@lwn.net> wrote:
> Jani Nikula (13):
>   Documentation/admin-guide: split the kernel parameter list to a 
> separate file
>   Documentation/admin-guide: split the device list to a separate file

Please note that in the mean time, several other documents and source files
have already been updated to point to
Documentation/admin-guide/kernel-parameters.rst resp. devices.rst.
These need to be updated again to point to the new *.txt files.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option

[Geert Uytterhoeven]

Hi Konrad,

On Mon, Oct 31, 2016 at 6:52 PM, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> On Mon, Oct 31, 2016 at 04:45:04PM +0100, Geert Uytterhoeven wrote:
>> On architectures like arm64, swiotlb is tied intimately to the core
>> architecture DMA support. In addition, ZONE_DMA cannot be disabled.
>>
>> To aid debugging and catch devices not supporting DMA to memory outside
>> the 32-bit address space, add a kernel command line option
>> "swiotlb=nobounce", which disables the use of bounce buffers.
>> If specified, trying to map memory that cannot be used with DMA will
>> fail, and a warning will be printed (rate-limited).
>
> I would make the 'swiotlb_force' an enum. And then instead of this
> being 'nobounce' just do the inverse of 'force', that is the
> 'noforce' would trigger this no bounce effect.
>
> So:
>
> enum {
> NORMAL, /* Default - depending on the hardware DMA mask and 
> such. */
> FORCE,  /* swiotlb=force */
> NO_FORCE,   /* swiotlb=noforce */

Fine for me, but swiotlb_force is exported to platform code. Hence all users
should be updated?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option

[Geert Uytterhoeven]

Hi Robin,

On Tue, Nov 1, 2016 at 12:46 PM, Robin Murphy <robin.mur...@arm.com> wrote:
>>>> To aid debugging and catch devices not supporting DMA to memory outside
>>>> the 32-bit address space, add a kernel command line option
>>>> "swiotlb=nobounce", which disables the use of bounce buffers.
>>>> If specified, trying to map memory that cannot be used with DMA will
>>>> fail, and a warning will be printed (rate-limited).
>>>
>>> This rationale seems questionable - how useful is non-deterministic
>>> behaviour for debugging really? What you end up with is DMA sometimes
>>> working or sometimes not depending on whether allocations happen to
>>> naturally fall below 4GB or not. In my experience, that in itself can be
>>> a pain in the arse to debug.
>>
>> It immediately triggered for me, though:
>>
>> rcar-dmac e730.dma-controller: Cannot do DMA to address
>> 0x00067a9b7000
>> ravb e680.ethernet: Cannot do DMA to address 0x00067aa07780
>>
>>> Most of the things you might then do to make things more deterministic
>>> again (like making the default DMA mask tiny or hacking out all the
>>> system's 32-bit addressable RAM) are also generally sufficient to make
>>> DMA fail earlier and make this option moot anyway. What's the specific
>>> use case motivating this?
>>
>> My use case is finding which drivers and DMA engines do not support 64-bit
>> memory. There's more info in my series "[PATCH/RFC 0/5] arm64: r8a7796: 
>> 64-bit
>> Memory and Ethernet Prototype"
>> (https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg08393.html)
>
> Thanks for the context. I've done very similar things in the past, and
> my first instinct would be to change the default DMA mask in
> of_dma_configure() to something which can't reach RAM (e.g. <30 bits),
> then instrument dma_set_mask() to catch cleverer drivers. That's a
> straightforward way to get 100% coverage - the problem with simply
> disabling bounce buffering is that whilst statistically it almost
> certainly will catch >95% of cases, there will always be some that it
> won't; if some driver only ever does a single dma_alloc_coherent() early
> enough that allocations are still fairly deterministic, and always
> happens to get a 32-bit address on that platform, it's likely to slip
> through the net.
>
> I'm not against the idea of SWIOTLB growing a runtime-disable option,
> I'm just not sure what situation it's actually the best solution for.

If I set the DMA mask to a small value, DMA is never used, and SWIOTLB
always falls back to bounce buffers (and DMAing from the small pool)?

That's the inverse of what I want to achieve: I want to avoid using the
bounce feature, to make sure the DMA engine is always used with whatever
kind of memory.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option

[Geert Uytterhoeven]

Hi Robin,

On Mon, Oct 31, 2016 at 6:41 PM, Robin Murphy <robin.mur...@arm.com> wrote:
> On 31/10/16 15:45, Geert Uytterhoeven wrote:
>> On architectures like arm64, swiotlb is tied intimately to the core
>> architecture DMA support. In addition, ZONE_DMA cannot be disabled.
>
> To be fair, that only takes a single-character change in
> arch/arm64/Kconfig - in fact, I'm amused to see my stupid patch to fix
> the build if you do just that (86a5906e4d1d) has just had its birthday ;)

Unfortunately it's not that simple. Using a small patch (based on Mark Salter's
"arm64: make CONFIG_ZONE_DMA user settable"), it appears to work. However:
  - With CONFIG_ZONE_DMA=n and memory present over 4G, swiotlb_init() is
not called.
This will lead to a NULL pointer dereference later, when
dma_map_single() calls into an unitialized SWIOTLB subsystem through
swiotlb_tbl_map_single().
  - With CONFIG_ZONE_DMA=n and no memory present over 4G, swiotlb_init()
is also not called, but RAVB works fine.
Disabling CONFIG_SWIOTLB is non-trivial, as the arm64 DMA core always
uses swiotlb_dma_ops, and its operations depend a lot on SWIOTLB
helpers.

So that's why I went for this option.

>> To aid debugging and catch devices not supporting DMA to memory outside
>> the 32-bit address space, add a kernel command line option
>> "swiotlb=nobounce", which disables the use of bounce buffers.
>> If specified, trying to map memory that cannot be used with DMA will
>> fail, and a warning will be printed (rate-limited).
>
> This rationale seems questionable - how useful is non-deterministic
> behaviour for debugging really? What you end up with is DMA sometimes
> working or sometimes not depending on whether allocations happen to
> naturally fall below 4GB or not. In my experience, that in itself can be
> a pain in the arse to debug.

It immediately triggered for me, though:

rcar-dmac e730.dma-controller: Cannot do DMA to address
0x00067a9b7000
ravb e680.ethernet: Cannot do DMA to address 0x00067aa07780

> Most of the things you might then do to make things more deterministic
> again (like making the default DMA mask tiny or hacking out all the
> system's 32-bit addressable RAM) are also generally sufficient to make
> DMA fail earlier and make this option moot anyway. What's the specific
> use case motivating this?

My use case is finding which drivers and DMA engines do not support 64-bit
memory. There's more info in my series "[PATCH/RFC 0/5] arm64: r8a7796: 64-bit
Memory and Ethernet Prototype"
(https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg08393.html)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] swiotlb: Rate-limit printing and 64-bit memory debugging

[Geert Uytterhoeven]

Hi Konrad, Jon,

This patch series contains two improvements for the SWIOTLB subsystem.

The first patch adds rate-limiting to an error message, to avoid
flooding the kernel log.
The second patch adds a kernel command line option to aid debugging when
developing support for DMA to memory outside the 32-bit address space.

Thanks for your comments!

Geert Uytterhoeven (2):
  swiotlb: Rate-limit printing when running out of SW-IOMMU space
  swiotlb: Add swiotlb=nobounce debug option

 Documentation/kernel-parameters.txt |  3 ++-
 lib/swiotlb.c   | 23 +++
 2 files changed, 21 insertions(+), 5 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] swiotlb: Add swiotlb=nobounce debug option

[Geert Uytterhoeven]

On architectures like arm64, swiotlb is tied intimately to the core
architecture DMA support. In addition, ZONE_DMA cannot be disabled.

To aid debugging and catch devices not supporting DMA to memory outside
the 32-bit address space, add a kernel command line option
"swiotlb=nobounce", which disables the use of bounce buffers.
If specified, trying to map memory that cannot be used with DMA will
fail, and a warning will be printed (rate-limited).

Note that io_tlb_nslabs is set to 1, which is the minimal supported
value.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/kernel-parameters.txt |  3 ++-
 lib/swiotlb.c   | 19 +--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf91f2cb6de2..38556cdceabaf087 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3998,10 +3998,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
it if 0 is given (See 
Documentation/cgroup-v1/memory.txt)
 
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
-   Format: {  | force }
+   Format: {  | force | nobounce }
 -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel
+   nobounce -- Never use bounce buffers (for debugging)
 
switches=   [HW,M68k]
 
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 6ce764410ae475cc..4550e6b516c2a4c0 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -54,6 +54,7 @@
 #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
 
 int swiotlb_force;
+static int swiotlb_nobounce;
 
 /*
  * Used to do a quick range check in swiotlb_tbl_unmap_single and
@@ -106,8 +107,12 @@
}
if (*str == ',')
++str;
-   if (!strcmp(str, "force"))
+   if (!strcmp(str, "force")) {
swiotlb_force = 1;
+   } else if (!strcmp(str, "nobounce")) {
+   swiotlb_nobounce = 1;
+   io_tlb_nslabs = 1;
+   }
 
return 0;
 }
@@ -541,8 +546,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
 map_single(struct device *hwdev, phys_addr_t phys, size_t size,
   enum dma_data_direction dir)
 {
-   dma_addr_t start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
+   dma_addr_t start_dma_addr;
+
+   if (swiotlb_nobounce) {
+   dev_warn_ratelimited(hwdev, "Cannot do DMA to address %pa\n",
+);
+   return SWIOTLB_MAP_ERROR;
+   }
 
+   start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
return swiotlb_tbl_map_single(hwdev, start_dma_addr, phys, size, dir);
 }
 
@@ -707,6 +719,9 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
phys_addr_t tlb_addr,
 swiotlb_full(struct device *dev, size_t size, enum dma_data_direction dir,
 int do_panic)
 {
+   if (swiotlb_nobounce)
+   return;
+
/*
 * Ran out of IOMMU space for this operation. This is very bad.
 * Unfortunately the drivers cannot handle this operation properly.
-- 
1.9.1

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

[PATCH 1/2] swiotlb: Rate-limit printing when running out of SW-IOMMU space

[Geert Uytterhoeven]

If the system runs out of SW-IOMMU space, changes are high successive
requests will fail, too, flooding the kernel log.  This is true
especially for streaming DMA, which is typically used repeatedly outside
the driver's initialization routine.  Add rate-limiting to fix this.

While at it, get rid of the open-coded dev_name() handling by using the
appropriate dev_err_*() variant.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 lib/swiotlb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 22e13a0e19d76a2b..6ce764410ae475cc 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -714,8 +714,8 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
phys_addr_t tlb_addr,
 * When the mapping is small enough return a static buffer to limit
 * the damage, or panic when the transfer is too big.
 */
-   printk(KERN_ERR "DMA: Out of SW-IOMMU space for %zu bytes at "
-  "device %s\n", size, dev ? dev_name(dev) : "?");
+   dev_err_ratelimited(dev, "DMA: Out of SW-IOMMU space for %zu bytes\n",
+   size);
 
if (size <= io_tlb_overflow || !do_panic)
return;
-- 
1.9.1

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

Re: pyc files in source dir with O=

[Geert Uytterhoeven]

Hi Jani,

On Wed, Sep 7, 2016 at 3:28 PM, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Wed, 07 Sep 2016, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>> When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
>> in the source tree instead of in the build tree:
>>
>> $ git ls-files -o
>> Documentation/sphinx/kernel-doc.pyc
>> Documentation/sphinx/kernel_include.pyc
>> Documentation/sphinx/rstFlatTable.pyc
>> $
>>
>> This is with v4.8-rc5.
>>
>> With next-20160907, two more files appear:
>>
>> Documentation/sphinx/cdomain.pyc
>> Documentation/sphinx/load_config.pyc
>
> This should help
>
> diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
> index 92deea30b183..a4cba2d1aaf1 100644
> --- a/Documentation/Makefile.sphinx
> +++ b/Documentation/Makefile.sphinx
> @@ -53,6 +53,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
>
>  quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
>cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
> $(build)=Documentation/media all;\
> +   PYTHONDONTWRITEBYTECODE=1 \
> BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
> $(SPHINXBUILD) \
> -b $2 \

Thanks, that works (on next-20160907, doesn't apply to v4.8-rc5).
But IMHO it's a bit drastic. There's no way to let python create them in the
build directory instead?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[next] make htmldocs fails with "too many values to unpack"

[Geert Uytterhoeven]

On next-20160907, "make htmldocs" fails:

Exception occurred:
  File "/usr/lib/python2.7/dist-packages/sphinx/environment.py", line
1530, in create_index
for type, value, tid, main in entries:
ValueError: too many values to unpack
The full traceback has been saved in /tmp/sphinx-err-GYk3bJ.log, if
you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error
message can be provided next time.
A bug report can be filed in the tracker at
<https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!

It works fine on v4.8-rc5.

Full traceback:

# Sphinx version: 1.2.2
# Python version: 2.7.6
# Docutils version: 0.11 release
# Jinja2 version: 2.7.2
# Loaded extensions:
#   kernel_include from
/linux-next/Documentation/sphinx/kernel_include.pyc
#   kernel-doc from /linux-next/Documentation/sphinx/kernel-doc.pyc
#   rstFlatTable from /linux-next/Documentation/sphinx/rstFlatTable.pyc
#   cdomain from /linux-next/Documentation/sphinx/cdomain.pyc
#   sphinx.ext.pngmath from
/usr/lib/python2.7/dist-packages/sphinx/ext/pngmath.pyc
#   sphinx.ext.oldcmarkup from
/usr/lib/python2.7/dist-packages/sphinx/ext/oldcmarkup.pyc
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 254, in main
app.build(force_all, filenames)
  File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line
212, in build
self.builder.build_update()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py",
line 214, in build_update
'out of date' % len(to_build))
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/__init__.py",
line 279, in build
self.finish()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py",
line 458, in finish
self.write_genindex()
  File "/usr/lib/python2.7/dist-packages/sphinx/builders/html.py",
line 492, in write_genindex
genindex = self.env.create_index(self)
  File "/usr/lib/python2.7/dist-packages/sphinx/environment.py", line
1530, in create_index
for type, value, tid, main in entries:
ValueError: too many values to unpack

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pyc files in source dir with O=

[Geert Uytterhoeven]

When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
in the source tree instead of in the build tree:

$ git ls-files -o
Documentation/sphinx/kernel-doc.pyc
Documentation/sphinx/kernel_include.pyc
Documentation/sphinx/rstFlatTable.pyc
$

This is with v4.8-rc5.

With next-20160907, two more files appear:

Documentation/sphinx/cdomain.pyc
Documentation/sphinx/load_config.pyc

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] documentation/scsi: Remove nodisconnect parameter

[Geert Uytterhoeven]

On Sat, Aug 27, 2016 at 4:29 AM, Finn Thain <fth...@telegraphics.com.au> wrote:
> The driver that used the 'nodisconnect' parameter was removed in
> commit 565bae6a4a8f ("[SCSI] 53c7xx: kill driver"). Related documentation
> was cleaned up in commit f37a7238d379 ("[SCSI] 53c7xx: fix removal
> fallout"), except for the remaining two mentions that are removed here.
>
> Signed-off-by: Finn Thain <fth...@telegraphics.com.au>

Reviewed-by: Geert Uytterhoeven <ge...@linux-m68k.org>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Documentation: clk: update file names containing referenced structures

[Geert Uytterhoeven]

From: Andi Shyti <andi.sh...@samsung.com>

Commit 'b09d6d991' removes include/linux/clk-private.h and
re-arranges the clock related structures contained in it in
different files. The documentation has not been updated
accordingly, thus it wasn't anymore consistent.

Place the structures referenced by Documentation/clk.txt in the
correct files and update their contents to the latest status.

Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
[geert: Fix path to clk.c, whitespace, more clk_core, ...]
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v2:
  - Take over from Andi,
  - Correct path to clk.c,
  - Drop whitespace changes,
  - Replace clk by clk_core where appropriate,
  - Update to_clk_gate(),
  - Drop final reference to clk-private.h.
---
 Documentation/clk.txt | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 5c4bc4d01d0c3293..22f026aa2f342024 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -31,24 +31,25 @@ serve as a convenient shorthand for the implementation of 
the
 hardware-specific bits for the hypothetical "foo" hardware.
 
 Tying the two halves of this interface together is struct clk_hw, which
-is defined in struct clk_foo and pointed to within struct clk.  This
+is defined in struct clk_foo and pointed to within struct clk_core.  This
 allows for easy navigation between the two discrete halves of the common
 clock interface.
 
Part 2 - common data structures and api
 
-Below is the common struct clk definition from
-include/linux/clk-private.h, modified for brevity:
+Below is the common struct clk_core definition from
+drivers/clk/clk.c, modified for brevity:
 
-   struct clk {
+   struct clk_core {
const char  *name;
const struct clk_ops*ops;
struct clk_hw   *hw;
-   char**parent_names;
-   struct clk  **parents;
-   struct clk  *parent;
-   struct hlist_head   children;
-   struct hlist_node   child_node;
+   struct module   *owner;
+   struct clk_core *parent;
+   const char  **parent_names;
+   struct clk_core **parents;
+   u8  num_parents;
+   u8  new_parent_index;
...
};
 
@@ -56,16 +57,19 @@ The members above make up the core of the clk tree 
topology.  The clk
 api itself defines several driver-facing functions which operate on
 struct clk.  That api is documented in include/linux/clk.h.
 
-Platforms and devices utilizing the common struct clk use the struct
-clk_ops pointer in struct clk to perform the hardware-specific parts of
-the operations defined in clk.h:
+Platforms and devices utilizing the common struct clk_core use the struct
+clk_ops pointer in struct clk_core to perform the hardware-specific parts of
+the operations defined in clk-provider.h:
 
struct clk_ops {
int (*prepare)(struct clk_hw *hw);
void(*unprepare)(struct clk_hw *hw);
+   int (*is_prepared)(struct clk_hw *hw);
+   void(*unprepare_unused)(struct clk_hw *hw);
int (*enable)(struct clk_hw *hw);
void(*disable)(struct clk_hw *hw);
int (*is_enabled)(struct clk_hw *hw);
+   void(*disable_unused)(struct clk_hw *hw);
unsigned long   (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);
long(*round_rate)(struct clk_hw *hw,
@@ -84,6 +88,8 @@ the operations defined in clk.h:
u8 index);
unsigned long   (*recalc_accuracy)(struct clk_hw *hw,
unsigned long parent_accuracy);
+   int (*get_phase)(struct clk_hw *hw);
+   int (*set_phase)(struct clk_hw *hw, int degrees);
void(*init)(struct clk_hw *hw);
int (*debug_init)(struct clk_hw *hw,
  struct dentry *dentry);
@@ -91,7 +97,7 @@ the operations defined in clk.h:
 
Part 3 - hardware clk implementations
 
-The strength of the common struct clk comes from its .ops and .hw pointers
+The strength of the common struct clk_core comes from its .ops and .hw pointers
 which abstract the details of struct clk from the hardware-specific bits, and
 vice versa.  To illustrate consider the simple gateable clk implementation in
 drivers/clk/clk-gate.c:
@@ -107,7 +113,7

[PATCH 1/2] serial: doc: Always refer to tty_port->mutex

[Geert Uytterhoeven]

Stop referring to the mutex member of the tty_port struct as
'port->mutex', as 'port' is ambiguous, and usually refers to the
uart_port struct in this document.  Use 'tty_port->mutex' instead,
following the single existing use.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 39701515832b70b0..90889c785809cde1 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -57,7 +57,7 @@ locking.
 The port_sem semaphore is used to protect against ports being added/
 removed or reconfigured at inappropriate times. Since v2.6.27, this
 semaphore has been the 'mutex' member of the tty_port struct, and
-commonly referred to as the port mutex (or port->mutex).
+commonly referred to as the port mutex.
 
 
 uart_ops
@@ -186,7 +186,7 @@ hardware.
should be terminated when another call is made with a zero
ctl.
 
-   Locking: caller holds port->mutex
+   Locking: caller holds tty_port->mutex
 
   startup(port)
Grab any interrupt resources and initialise any low level driver
@@ -262,14 +262,14 @@ hardware.
Other flags may be used (eg, xon/xoff characters) if your
hardware supports hardware "soft" flow control.
 
-   Locking: caller holds port->mutex
+   Locking: caller holds tty_port->mutex
Interrupts: caller dependent.
This call must not sleep
 
   set_ldisc(port,termios)
Notifier for discipline change. See Documentation/serial/tty.txt.
 
-   Locking: caller holds port->mutex
+   Locking: caller holds tty_port->mutex
 
   pm(port,state,oldstate)
Perform any power management related activities on the specified
-- 
1.9.1

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

[PATCH 0/2] serial: doc: More Low Level Serial API Documentation Improvements

[Geert Uytterhoeven]

Hi Greg, Jiri, Jon, Peter, Russell,

This patch series (against next-20160511) contains improvements to the low
level serial driver API documentation.

Thanks for your comments!

Geert Uytterhoeven (2):
  serial: doc: Always refer to tty_port->mutex
  serial: doc: Use port->state instead of info

 Documentation/serial/driver | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] serial: doc: Use port->state instead of info

[Geert Uytterhoeven]

As of commit ebd2c8f6d2ec4012 ("serial: kill off uart_info"), the
circular transmission buffer is part of struct uart_state instead of
struct uart_info. Make it clear this structure is pointed to from struct
uart_port.

Change 'circ' to 'circ_buf' to match the structure name while we're at
it.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 90889c785809cde1..da193e092fc3d531 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -48,8 +48,8 @@ data:
 
port->mctrl
port->icount
-   info->xmit.head (circ->head)
-   info->xmit.tail (circ->tail)
+   port->state->xmit.head (circ_buf->head)
+   port->state->xmit.tail (circ_buf->tail)
 
 The low level driver is free to use this lock to provide any additional
 locking.
@@ -204,7 +204,7 @@ hardware.
RTS nor DTR; this will have already been done via a separate
call to set_mctrl.
 
-   Drivers must not access port->info once this call has completed.
+   Drivers must not access port->state once this call has completed.
 
This method will only be called when there are no more users of
this port.
@@ -216,7 +216,7 @@ hardware.
Flush any write buffers, reset any DMA state and stop any
ongoing DMA transfers.
 
-   This will be called whenever the port->info->xmit circular
+   This will be called whenever the port->state->xmit circular
buffer is cleared.
 
Locking: port->lock taken.
-- 
1.9.1

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

[PATCH -trivial 1/3] Documentation: vm: Spelling s/paltform/platform/g

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/vm/hugetlbpage.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index 54dd9b9c6c31aeed..6f3b3fa35613d900 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -275,10 +275,10 @@ This command mounts a (pseudo) filesystem of type 
hugetlbfs on the directory
 options sets the owner and group of the root of the file system.  By default
 the uid and gid of the current process are taken.  The mode option sets the
 mode of root of file system to value & 01777.  This value is given in octal.
-By default the value 0755 is picked. If the paltform supports multiple huge
+By default the value 0755 is picked. If the platform supports multiple huge
 page sizes, the pagesize option can be used to specify the huge page size and
 associated pool.  pagesize is specified in bytes.  If pagesize is not specified
-the paltform's default huge page size and associated pool will be used. The
+the platform's default huge page size and associated pool will be used. The
 size option sets the maximum value of memory (huge pages) allowed for that
 filesystem (/mnt/huge).  The size option can be specified in bytes, or as a
 percentage of the specified huge page pool (nr_hugepages).  The size is
-- 
1.9.1

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

[PATCH -trivial 2/3] ARM: Spelling s/paltform/platform/g

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2d756aa471f33316..c01039b81d6eeb13 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -897,7 +897,7 @@ config MACH_STM32F429
default y
 
 config ARCH_MPS2
-   bool "ARM MPS2 paltform"
+   bool "ARM MPS2 platform"
depends on ARM_SINGLE_ARMV7M
select ARM_AMBA
select CLKSRC_MPS2
-- 
1.9.1

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

[PATCH -trivial 3/3] spi: dw-pci: Spelling s/paltforms/platforms/g

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 drivers/spi/spi-dw-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-dw-pci.c b/drivers/spi/spi-dw-pci.c
index 332ccb0539a77710..ef7db75c92c13b34 100644
--- a/drivers/spi/spi-dw-pci.c
+++ b/drivers/spi/spi-dw-pci.c
@@ -67,7 +67,7 @@ static int spi_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
dws->irq = pdev->irq;
 
/*
-* Specific handling for paltforms, like dma setup,
+* Specific handling for platforms, like dma setup,
 * clock rate, FIFO depth.
 */
if (desc) {
-- 
1.9.1

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

Re: [PATCH 4/4] serial: doc: .break_ctl() may sleep

[Geert Uytterhoeven]

Hi Jon,

On Sat, Apr 16, 2016 at 6:47 PM, Jonathan Corbet <cor...@lwn.net> wrote:
> On Fri, 15 Apr 2016 16:07:39 -0700
> Peter Hurley <pe...@hurleysoftware.com> wrote:
>
>> > I'm missing something here.
>>
>> Yes.
>>
>> The analysis above is required to show that the API contract asserted by
>> the proposed change to the documentation is currently true in the code,
>> which is what I care about.
>
> Yes, but the analysis says nothing about what uart_break_ctl() itself
> might do, so by itself, it provides no guarantee for break_ctl().  That
> was my sticking point since somebody clearly put that line in there for a
> reason.
>
> Looking at the code, it's pretty obvious that uart_break_ctl() isn't
> acquiring any spinlocks.  The documentation line in question has been
> there, unchanged, since the beginning of the Git era.  The patch is
> obviously fine, and I've applied it, but I did tweak the changelog some.

Sorry, this indeed needed more clarification.
Thanks for fixing it up!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] serial: doc: .break_ctl() may sleep

[Geert Uytterhoeven]

As mutex_lock() must not be called with interrupts disabled,
.break_ctl() may sleep.

Reported-by: Peter Hurley <pe...@hurleysoftware.com>
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 7fb80682e394eb76..39701515832b70b0 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -187,7 +187,6 @@ hardware.
ctl.
 
Locking: caller holds port->mutex
-   This call must not sleep
 
   startup(port)
Grab any interrupt resources and initialise any low level driver
-- 
1.9.1

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

[PATCH 0/4] serial: doc: Low Level Serial API Documentation Improvements (take two)

[Geert Uytterhoeven]

Hi Greg, Jiri, Jon, Peter, Russell,

This patch series contains improvements to the low level serial driver
API documentation.

It is an incremental update (sort of v2) of "[PATCH 0/9] serial: doc:
Low Level Serial API Documentation Improvements", which was already
applied to the docs tree.

Thanks for your comments!

Geert Uytterhoeven (4):
  serial: doc: Re-add paragraph documenting uart_console_write()
  serial: doc: .(un)throttle() depends on hardware assisted flow control
  serial: doc: .(un)throttle() are serialized by the tty layer
  serial: doc: .break_ctl() may sleep

 Documentation/serial/driver | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Prefer kASLR over Hibernation

[Geert Uytterhoeven]

On Mon, Apr 11, 2016 at 8:03 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Mon, Apr 11, 2016 at 1:00 AM, James Morse <james.mo...@arm.com> wrote:
>> On 06/04/16 20:44, Kees Cook wrote:
>>> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
>>> one or the other must be chosen at boot-time. Until now, hibernation
>>> was selected when no choice was made on the command line.
>>>
>>> To make the security benefits of kASLR more widely available to end
>>> users (since the use of hibernation is becoming more rare and kASLR,
>>> already available on x86, will be available on arm64 and MIPS soon),
>>> this changes the default to preferring kASLR over hibernation. Users
>>> wanting hibernation can turn off kASLR by adding "nokaslr" to the kernel
>>> command line.
>>
>> While hibernate isn't yet merged for arm64, it does work with kASLR in 
>> v4.6-rc*,
>> it would be a shame to have to choose at boot time, (but that's my problem to
>> fix if/when its merged).
>
> Ah, interesting, so they work together on arm64? (i.e. you've actually
> tested a boot loader that provides the seed for kASLR to operate?)

Probably the PS3 people can provide us with a good tool to generate a
seed that makes hibernation work all the time ;-)

https://xkcd.com/221/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Geert Uytterhoeven]

On Wed, Apr 6, 2016 at 2:29 PM, Yury Norov <yno...@caviumnetworks.com> wrote:
>> We're already closer to the (future) y2038 than to the (past) introduction of
>> LP64...
>
> This is not about Y2038 at all. In fact, current version doesn't fix
> Y2038 problem, as we decided finally.

Indeed. So these legacy applications have to be fixed later anyway.

Gr{oetje,eeting}s,

        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Geert Uytterhoeven]

Hi Yuri,

On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov <yno...@caviumnetworks.com> wrote:
> This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem.
> It works with updated glibc [1] (though very draft), and tested with LTP.
>
> It was tested on QEMU and ThunderX machines. No major difference found.
> This is RFC because ILP32 is not tested in big-endian mode.
>
>  v3: https://lkml.org/lkml/2014/9/3/704
>  v4: https://lkml.org/lkml/2015/4/13/691
>  v5: https://lkml.org/lkml/2015/9/29/911
>
>  v6:
>  - time_t, __kenel_off_t and other types turned to be 32-bit
>for compatibility reasons (after v5 discussion);

Reading this sparked my interest, so I went to the links above...

What makes you think these "applications that can’t readily be migrated to LP64
because they were written assuming an ILP32 data model, and that will never
become suitable for a LP64 data model and will remain locked into ILP32
operating environments" are more likely to be fixed for y2038 later, than for
LP64 now?

We're already closer to the (future) y2038 than to the (past) introduction of
LP64...

These unfixable legacy applications have been spreading through x32 to
the shiny new arm64 server architecture (does ppc64el also have an ILP32 mode,
or is it planned)? Lots of resources are spent on maintaining the status quo,
instead of on fixing the real problems.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] serial: doc: Low Level Serial API Documentation Improvements

[Geert Uytterhoeven]

Hi Jon,

On Thu, Mar 31, 2016 at 8:59 AM, Jonathan Corbet <cor...@lwn.net> wrote:
> On Mon, 14 Mar 2016 16:16:08 +0100
> Geert Uytterhoeven <geert+rene...@glider.be> wrote:
>
>> This patch series contains improvements to the low level serial driver
>> API documentation.
>
> Hearing no objections, I've applied the set to the docs tree, thanks.

There were a few from Peter Hurley, and I planned to send an updated
version soon.

Gr{oetje,eeting}s,

    Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] fat: add config option to set UTF-8 mount option by default

[Geert Uytterhoeven]

On Wed, Mar 23, 2016 at 12:28 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Wed, Mar 23, 2016 at 4:17 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
>> On Tue, Mar 8, 2016 at 2:53 PM, Maciej S. Szmigiero
>> <m...@maciej.szmigiero.name> wrote:
>>> FAT has long supported its own default file name encoding
>>> config setting, separate from CONFIG_NLS_DEFAULT.
>>>
>>> However, if UTF-8 encoded file names are desired FAT
>>> character set should not be set to utf8 since this would
>>> make file names case sensitive even if case insensitive
>>> matching is requested.
>>> Instead, "utf8" mount options should be provided to enable
>>> UTF-8 file names in FAT file system.
>>>
>>> Unfortunately, there was no possibility to set the default
>>> value of this option so on UTF-8 system "utf8" mount option
>>> had to be added manually to most FAT mounts.
>>>
>>> This patch adds config option to set such default value.
>>>
>>> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
>>
>>> --- a/fs/fat/Kconfig
>>> +++ b/fs/fat/Kconfig
>>> @@ -93,8 +93,24 @@ config FAT_DEFAULT_IOCHARSET
>>>   that most of your FAT filesystems use, and can be overridden
>>>   with the "iocharset" mount option for FAT filesystems.
>>>   Note that "utf8" is not recommended for FAT filesystems.
>>> - If unsure, you shouldn't set "utf8" here.
>>> + If unsure, you shouldn't set "utf8" here - select the next option
>>> + instead if you would like to use UTF-8 encoded file names by 
>>> default.
>>>   See  for more 
>>> information.
>>>
>>>   Enable any character sets you need in File Systems/Native Language
>>>   Support.
>>> +
>>> +config FAT_DEFAULT_UTF8
>>> +   bool "Enable FAT UTF-8 option by default"
>>> +   depends on VFAT_FS
>>> +   default n
>>> +   help
>>> + Set this if you would like to have "utf8" mount option set
>>> + by default when mounting FAT filesystems.
>>> +
>>> + Even if you say Y here can always disable UTF-8 for
>>> + particular mount by adding "utf8=0" to mount options.
>>> +
>>> + Say Y if you use UTF-8 encoding for file names, N otherwise.
>>> +
>>> + See  for more 
>>> information.
>>
>> What's the recommended value of CONFIG_FAT_DEFAULT_UTF8 for
>> a (distro) defconfig?
>
> Yes, I'm curious about this as well.  My initial assumption is to
> leave it off, given that if you turn it on when it wasn't previously
> it will change the behavior.  I would also assume that is why it is
> marked as default n.

"default n" is superfluous, as all options default to "n" in the absence
of a default specifier.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] fat: add config option to set UTF-8 mount option by default

[Geert Uytterhoeven]

On Tue, Mar 8, 2016 at 2:53 PM, Maciej S. Szmigiero
<m...@maciej.szmigiero.name> wrote:
> FAT has long supported its own default file name encoding
> config setting, separate from CONFIG_NLS_DEFAULT.
>
> However, if UTF-8 encoded file names are desired FAT
> character set should not be set to utf8 since this would
> make file names case sensitive even if case insensitive
> matching is requested.
> Instead, "utf8" mount options should be provided to enable
> UTF-8 file names in FAT file system.
>
> Unfortunately, there was no possibility to set the default
> value of this option so on UTF-8 system "utf8" mount option
> had to be added manually to most FAT mounts.
>
> This patch adds config option to set such default value.
>
> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>

> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -93,8 +93,24 @@ config FAT_DEFAULT_IOCHARSET
>   that most of your FAT filesystems use, and can be overridden
>   with the "iocharset" mount option for FAT filesystems.
>   Note that "utf8" is not recommended for FAT filesystems.
> - If unsure, you shouldn't set "utf8" here.
> + If unsure, you shouldn't set "utf8" here - select the next option
> + instead if you would like to use UTF-8 encoded file names by 
> default.
>   See  for more information.
>
>   Enable any character sets you need in File Systems/Native Language
>   Support.
> +
> +config FAT_DEFAULT_UTF8
> +   bool "Enable FAT UTF-8 option by default"
> +   depends on VFAT_FS
> +   default n
> +   help
> + Set this if you would like to have "utf8" mount option set
> + by default when mounting FAT filesystems.
> +
> + Even if you say Y here can always disable UTF-8 for
> + particular mount by adding "utf8=0" to mount options.
> +
> + Say Y if you use UTF-8 encoding for file names, N otherwise.
> +
> + See  for more information.

What's the recommended value of CONFIG_FAT_DEFAULT_UTF8 for
a (distro) defconfig?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/9] serial: doc: Document .throttle()

[Geert Uytterhoeven]

On Mon, Mar 14, 2016 at 4:16 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
>  Documentation/serial/driver | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/serial/driver b/Documentation/serial/driver
> index 61d520dea4c6e13a..50f3d94ed50b341e 100644
> --- a/Documentation/serial/driver
> +++ b/Documentation/serial/driver
> @@ -126,6 +126,13 @@ hardware.
> Interrupts: locally disabled.
> This call must not sleep
>
> +  throttle(port)
> +   Notify the serial driver that input buffers for the line discipline 
> are
> +   close to full, and it should somehow signal that no more characters
> +   should be sent to the serial port.
> +
> +   Locking: none.
> +

In the mean time I discovered this (and .unthrottle()) is used with hardware
assisted flow control only, and when it was introduced.
Will update the documentation accordingly.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] serial: doc: Un-document obsolete tmpbuf_sem

[Geert Uytterhoeven]

uart_info.tmpbuf and uart_info.tmpbuf_sem were removed in v2.6.10, in
full-history-linux commit a797ad7e3ae9cad4 ("[SERIAL] Clean up
serial_core.c write functions.").

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index e7c6f86ee06f9927..61d520dea4c6e13a 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -36,8 +36,7 @@ It is the responsibility of the low level hardware driver to 
perform the
 necessary locking using port->lock.  There are some exceptions (which
 are described in the uart_ops listing below.)
 
-There are three locks.  A per-port spinlock, a per-port tmpbuf semaphore,
-and an overall semaphore.
+There are two locks.  A per-port spinlock, and an overall semaphore.
 
 From the core driver perspective, the port->lock locks the following
 data:
@@ -50,9 +49,6 @@ data:
 The low level driver is free to use this lock to provide any additional
 locking.
 
-The core driver uses the info->tmpbuf_sem lock to prevent multi-threaded
-access to the info->tmpbuf bouncebuffer used for port writes.
-
 The port_sem semaphore is used to protect against ports being added/
 removed or reconfigured at inappropriate times. Since v2.6.27, this
 semaphore has been the 'mutex' member of the tty_port struct, and
-- 
1.9.1

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

[PATCH 6/9] serial: doc: .break_ctl() is called with port->mutex() held

[Geert Uytterhoeven]

Note that mutex_lock() should not be called with interrupts disabled.

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 3b08df5bcc17e944..09e73e061fcf795c 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -177,8 +177,7 @@ hardware.
should be terminated when another call is made with a zero
ctl.
 
-   Locking: none.
-   Interrupts: caller dependent.
+   Locking: caller holds port->mutex
This call must not sleep
 
   startup(port)
-- 
1.9.1

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

[PATCH 5/9] serial: doc: Document .set_ldisc()

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 3b2a97d5ecc79491..3b08df5bcc17e944 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -259,6 +259,11 @@ hardware.
Interrupts: caller dependent.
This call must not sleep
 
+  set_ldisc(port,termios)
+   Notifier for discipline change. See Documentation/serial/tty.txt.
+
+   Locking: caller holds port->mutex
+
   pm(port,state,oldstate)
Perform any power management related activities on the specified
port.  State indicates the new state (defined by
-- 
1.9.1

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

[PATCH 3/9] serial: doc: Document .throttle()

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 61d520dea4c6e13a..50f3d94ed50b341e 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -126,6 +126,13 @@ hardware.
Interrupts: locally disabled.
This call must not sleep
 
+  throttle(port)
+   Notify the serial driver that input buffers for the line discipline are
+   close to full, and it should somehow signal that no more characters
+   should be sent to the serial port.
+
+   Locking: none.
+
   send_xchar(port,ch)
Transmit a high priority character, even if the port is stopped.
This is used to implement XON/XOFF flow control and tcflow().  If
-- 
1.9.1

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

[PATCH 7/9] serial: doc: Spelling s/divsor/divisor/

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 09e73e061fcf795c..3706a465fe2d7427 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -380,7 +380,7 @@ uart_get_baud_rate(port,termios,old,min,max)
Interrupts: n/a
 
 uart_get_divisor(port,baud)
-   Return the divsor (baud_base / baud) for the specified baud
+   Return the divisor (baud_base / baud) for the specified baud
rate, appropriately rounded.
 
If 38400 baud and custom divisor is selected, return the
-- 
1.9.1

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

[PATCH 9/9] serial: doc: Correct return type of mctrl_gpio_to_gpiod()

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index ba84d1f38ca1d1e6..65de49a4b39e5baf 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -462,7 +462,8 @@ mctrl_gpio_free(dev, gpios):
this function.
 
 mctrl_gpio_to_gpiod(gpios, gidx)
-   This returns the gpio structure associated to the modem line index.
+   This returns the gpio_desc structure associated to the modem line
+   index.
 
 mctrl_gpio_set(gpios, mctrl):
This will sets the gpios according to the mctrl state.
-- 
1.9.1

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

[PATCH 4/9] serial: doc: Document .unthrottle()

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
 Documentation/serial/driver | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 50f3d94ed50b341e..3b2a97d5ecc79491 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -133,6 +133,13 @@ hardware.
 
Locking: none.
 
+  unthrottle(port)
+   Notify the serial driver that characters can now be sent to the serial
+   port without fear of overrunning the input buffers of the line
+   disciplines.
+
+   Locking: none.
+
   send_xchar(port,ch)
Transmit a high priority character, even if the port is stopped.
This is used to implement XON/XOFF flow control and tcflow().  If
-- 
1.9.1

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

[PATCH 0/9] serial: doc: Low Level Serial API Documentation Improvements

[Geert Uytterhoeven]

Hi Russell, Greg, Jiri, Jon,

This patch series contains improvements to the low level serial driver
API documentation.

Thanks for your comments!

Geert Uytterhoeven (9):
  serial: doc: Un-document non-existing uart_write_console()
  serial: doc: Un-document obsolete tmpbuf_sem
  serial: doc: Document .throttle()
  serial: doc: Document .unthrottle()
  serial: doc: Document .set_ldisc()
  serial: doc: .break_ctl() is called with port->mutex() held
  serial: doc: Spelling s/divsor/divisor/
  serial: doc: Grammar s/function are/functions are/
  serial: doc: Correct return type of mctrl_gpio_to_gpiod()

 Documentation/serial/driver | 40 +---
 1 file changed, 25 insertions(+), 15 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html