Re: [PATCH v3 2/4] soc: qcom: Add GENI based QUP Wrapper driver

2018-03-02 Thread Karthik Ramasubramanian 



On 3/2/2018 1:41 PM, Stephen Boyd wrote:

Quoting Karthikeyan Ramasubramanian (2018-02-27 17:38:07)

This driver manages the Generic Interface (GENI) firmware based Qualcomm
Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
programmable module composed of multiple Serial Engines (SE) and supports
a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
driver also enables managing the serial interface independent aspects of
Serial Engines.

Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
Signed-off-by: Girish Mahadevan 
---
  drivers/soc/qcom/Kconfig|   9 +
  drivers/soc/qcom/Makefile   |   1 +
  drivers/soc/qcom/qcom-geni-se.c | 971 
  include/linux/qcom-geni-se.h| 247 ++
  4 files changed, 1228 insertions(+)
  create mode 100644 drivers/soc/qcom/qcom-geni-se.c
  create mode 100644 include/linux/qcom-geni-se.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index e050eb8..cc460d0 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,15 @@
  #
  menu "Qualcomm SoC drivers"
  
+config QCOM_GENI_SE

+   tristate "QCOM GENI Serial Engine Driver"
+   depends on ARCH_QCOM


Add || COMPILE_TEST?

Ok.



+   help
+ This module is used to manage Generic Interface (GENI) firmware based


s/module/driver?


+ Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
+ module is also used to manage the common aspects of multiple Serial

s/module/driver?

Ok.



+ Engines present in the QUP.
+
  config QCOM_GLINK_SSR
 tristate "Qualcomm Glink SSR driver"
 depends on RPMSG
diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
new file mode 100644
index 000..61335b8
--- /dev/null
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -0,0 +1,971 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


#include 

Ok



+
+/**
+ * DOC: Overview
+ *
+ * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced
+ * to manage GENI firmware based Qualcomm Universal Peripheral (QUP) Wrapper
+ * controller. QUP Wrapper is designed to support various serial bus protocols
+ * like UART, SPI, I2C, I3C, etc.
+ */
+
+/**
+ * DOC: Hardware description
+ *
+ * GENI based QUP is a highly-flexible and programmable module for supporting
+ * a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single
+ * QUP module can provide upto 8 Serial Interfaces, using its internal
+ * Serial Engines. The actual configuration is determined by the target
+ * platform configuration. The protocol supported by each interface is
+ * determined by the firmware loaded to the Serial Engine. Each SE consists
+ * of a DMA Engine and GENI sub modules which enable Serial Engines to
+ * support FIFO and DMA modes of operation.
+ *
+ *
+ *  +-+
+ *  |QUP Wrapper  |
+ *  | ++  |
+ *   --QUP & SE Clocks--> | Serial Engine N|  +-IO-->
+ *  | | ...|  | Interface
+ *   <---Clock Perf.+++---+|  |
+ * State Interface  || Serial Engine 1||  |
+ *  ||||  |
+ *  ||||  |
+ *   |||  |
+ *  ||++  |
+ *  |||   |
+ *  |||   |
+ *   <--SE IRQ--+++   |
+ *  | |
+ *  +-+
+ *
+ * Figure 1: GENI based QUP Wrapper


The code talks about primary and secondary sequencers, but this hardware
description doesn't talk about it. Can you add some more information
here about that aspect too?

Ok.



+ */
+
+/**
+ * DOC: Software description
+ *
+ * GENI SE Wrapper driver is structured into 2 parts:
+ *
+ * geni_wrapper represents QUP Wrapper controller. This part of the driver
+ * manages QUP Wrapper information such as hardware version, clock
+ * performance table that is common to all the internal Serial Engines.
+ *
+ * geni_se represents Serial Engine. This part of the driver manages Serial
+ * Engine information such as clocks, containing QUP Wrapper etc. This part


Insert a

Re: [PATCH v3 4/4] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

2018-03-02 Thread Evan Green 
Hello Karthik,

On Tue, Feb 27, 2018 at 5:38 PM, Karthikeyan Ramasubramanian
 wrote:
> This driver supports GENI based UART Controller in the Qualcomm SOCs. The
> Qualcomm Generic Interface (GENI) is a programmable module supporting a
> wide range of serial interfaces including UART. This driver support console
> operations using FIFO mode of transfer.
>
> Signed-off-by: Girish Mahadevan 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/tty/serial/Kconfig|   11 +
>  drivers/tty/serial/Makefile   |1 +
>  drivers/tty/serial/qcom_geni_serial.c | 1181 
> +
>  3 files changed, 1193 insertions(+)
>  create mode 100644 drivers/tty/serial/qcom_geni_serial.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 3682fd3..c6b1500 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1104,6 +1104,17 @@ config SERIAL_MSM_CONSOLE
> select SERIAL_CORE_CONSOLE
> select SERIAL_EARLYCON
>
> +config SERIAL_QCOM_GENI
> +   bool "QCOM on-chip GENI based serial port support"
> +   depends on ARCH_QCOM
> +   depends on QCOM_GENI_SE

My understanding is that this has to be "bool" because there's a
console in there, and consoles cannot be built as modules. Stephen is
suggesting splitting this option up into two, so you could have serial
with or without the console. That's fine, and probably the preferred
way. However, you do want to make sure that if serial (or what's soon
to be serial+console) is enabled, that QCOM_GENI_SE has to be built
=y, and not =m. I'd suggest "select QCOM_GENI_SE" in the new
SERIAL_QCOM_GENI_CONSOLE (or whatever it's called). As it is now, if
SERIAL_QCOM_GENI=y and QCOM_GENI_SE=m, there's a build failure.

GENI_SE is allowed to be built as a module if serial is not enabled
and I2C is built as a module. In order to keep the dependency arrows
going in the same direction, you might want the I2C driver to "select
QCOM_GENI_SE" as well, in order to upgrade GENI_SE to y if I2C is y.

> diff --git a/drivers/tty/serial/qcom_geni_serial.c 
> b/drivers/tty/serial/qcom_geni_serial.c
> new file mode 100644
> index 000..8536b7d
> --- /dev/null
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -0,0 +1,1181 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* UART specific GENI registers */
> +#define SE_UART_TX_TRANS_CFG   0x25c
> +#define SE_UART_TX_WORD_LEN0x268
> +#define SE_UART_TX_STOP_BIT_LEN0x26c
> +#define SE_UART_TX_TRANS_LEN   0x270
> +#define SE_UART_RX_TRANS_CFG   0x280
> +#define SE_UART_RX_WORD_LEN0x28c
> +#define SE_UART_RX_STALE_CNT   0x294
> +#define SE_UART_TX_PARITY_CFG  0x2a4
> +#define SE_UART_RX_PARITY_CFG  0x2a8
> +
> +/* SE_UART_TRANS_CFG */
> +#define UART_TX_PAR_EN BIT(0)
> +#define UART_CTS_MASK  BIT(1)
> +
> +/* SE_UART_TX_WORD_LEN */
> +#define TX_WORD_LEN_MSKGENMASK(9, 0)
> +
> +/* SE_UART_TX_STOP_BIT_LEN */
> +#define TX_STOP_BIT_LEN_MSKGENMASK(23, 0)
> +#define TX_STOP_BIT_LEN_1  0
> +#define TX_STOP_BIT_LEN_1_51
> +#define TX_STOP_BIT_LEN_2  2
> +
> +/* SE_UART_TX_TRANS_LEN */
> +#define TX_TRANS_LEN_MSK   GENMASK(23, 0)
> +
> +/* SE_UART_RX_TRANS_CFG */
> +#define UART_RX_INS_STATUS_BIT BIT(2)
> +#define UART_RX_PAR_EN BIT(3)
> +
> +/* SE_UART_RX_WORD_LEN */
> +#define RX_WORD_LEN_MASK   GENMASK(9, 0)
> +
> +/* SE_UART_RX_STALE_CNT */
> +#define RX_STALE_CNT   GENMASK(23, 0)
> +
> +/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
> +#define PAR_CALC_ENBIT(0)
> +#define PAR_MODE_MSK   GENMASK(2, 1)
> +#define PAR_MODE_SHFT  1
> +#define PAR_EVEN   0x00
> +#define PAR_ODD0x01
> +#define PAR_SPACE  0x10
> +#define PAR_MARK   0x11
> +
> +/* UART M_CMD OP codes */
> +#define UART_START_TX  0x1
> +#define UART_START_BREAK   0x4
> +#define UART_STOP_BREAK0x5
> +/* UART S_CMD OP codes */
> +#define UART_START_READ0x1
> +#define UART_PARAM 0x1
> +
> +#define UART_OVERSAMPLING  32
> +#define STALE_TIMEOUT  16
> +#define DEFAULT_BITS_PER_CHAR  10
> +#define GENI_UART_CONS_PORTS   1
> +#define DEF_FIFO_DEPTH_WORDS   16
> +#define DEF_TX_WM  2
> +#define DEF_FIFO_WIDTH_BITS32
> +#define UART_CONSOLE_RX_WM 2
> +
> +#ifdef CONFIG_CONSOLE_POLL
> +#define RX_BYTES_PW 1
> +#else
> +#define RX_BYTES_PW 4
>

Re: [PATCH v2 0/2] mux: add overview and add to driver-api docs

2018-03-02 Thread Peter Rosin 
On 2017-12-21 23:11, Peter Rosin wrote:
> On 2017-12-21 22:35, Jonathan Corbet wrote:
>> On Tue, 12 Dec 2017 09:46:31 +0100
>> Peter Rosin  wrote:
>>
>>> Changes since v1:
>>> - added a short introductory paragraph to mux.rst
>>> - added an entry in MAINTAINERS.
>>>
>>> I forgot to mention that this applies on top of linux-next, I suspect
>>> there will be a trivial conflict with an SPDX conversion in mux/core.c
>>> on Linus upstream.
>>
>> Sorry, I've had this just sitting here for a bit.  Did you want me to take
>> both patches through the docs tree?
> 
> I think that's going to be easiest, thanks! Let me know if you want me
> to rebase them to something w/o the SPDX change.

Hi,

Gentle ping...

Cheers,
Peter
--
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] xfs: Change URL for the project in xfs.txt

2018-03-02 Thread Dave Chinner 
On Fri, Mar 02, 2018 at 04:08:24PM -0600, Eric Sandeen wrote:
> 
> 
> On 3/2/18 3:57 PM, Dave Chinner wrote:
> > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote:
> >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote:
> >>> The oss.sgi.com doesn't exist any more.
> >>> Change it to current project URL, https://xfs.wiki.kernel.org/
> >>>
> >>> Signed-off-by: Masanari Iida 
> >>> ---
> >>>  Documentation/filesystems/xfs.txt | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/filesystems/xfs.txt 
> >>> b/Documentation/filesystems/xfs.txt
> >>> index 3b9b5c149f32..4d9ff0a7f8e1 100644
> >>> --- a/Documentation/filesystems/xfs.txt
> >>> +++ b/Documentation/filesystems/xfs.txt
> >>> @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes 
> >>> extensive use of
> >>>  Btrees (directories, extents, free space) to aid both performance
> >>>  and scalability.
> >>>  
> >>> -Refer to the documentation at http://oss.sgi.com/projects/xfs/
> >>> +Refer to the documentation at https://xfs.wiki.kernel.org/
> > 
> > Did I miss a memo?
> 
> About which part, the loss of oss.sgi or the addition of the kernel.org wiki?
> 
> The kernel.org wiki is pretty bare though.  OTOH xfs.org is a bit less
> official.  We really need to resolve this issue.

Moving everything to kernel.org wiki. As I mentioned on IRC, I'd
much prefer we move away from wiki's to something we can edit
locally, review via email, has proper revision control and a
"publish" mechanism that pushes built documentation out to the
public website.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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 4/4] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

2018-03-02 Thread Stephen Boyd 
Quoting Karthikeyan Ramasubramanian (2018-02-27 17:38:09)
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 3682fd3..c6b1500 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1104,6 +1104,17 @@ config SERIAL_MSM_CONSOLE
> select SERIAL_CORE_CONSOLE
> select SERIAL_EARLYCON
>  
> +config SERIAL_QCOM_GENI
> +   bool "QCOM on-chip GENI based serial port support"

This can be tristate.

> +   depends on ARCH_QCOM

|| COMPILE_TEST
?

> +   depends on QCOM_GENI_SE
> +   select SERIAL_CORE

This can stay.

> +   select SERIAL_CORE_CONSOLE
> +   select SERIAL_EARLYCON

These two can go to a new config option, like SERIAL_QCOM_GENI_CONSOLE,
and that would be bool. Please take a look at the existing SERIAL_MSM
and SERIAL_MSM_CONSOLE setup to understand how to do it.

> +   help
> + Serial driver for Qualcomm Technologies Inc's GENI based QUP
> + hardware.
> +
>  config SERIAL_VT8500
> bool "VIA VT8500 on-chip serial port support"
> depends on ARCH_VT8500
> diff --git a/drivers/tty/serial/qcom_geni_serial.c 
> b/drivers/tty/serial/qcom_geni_serial.c
> new file mode 100644
> index 000..8536b7d
> --- /dev/null
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -0,0 +1,1181 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* UART specific GENI registers */
> +#define SE_UART_TX_TRANS_CFG   0x25c
> +#define SE_UART_TX_WORD_LEN0x268
> +#define SE_UART_TX_STOP_BIT_LEN0x26c
> +#define SE_UART_TX_TRANS_LEN   0x270
> +#define SE_UART_RX_TRANS_CFG   0x280
> +#define SE_UART_RX_WORD_LEN0x28c
> +#define SE_UART_RX_STALE_CNT   0x294
> +#define SE_UART_TX_PARITY_CFG  0x2a4
> +#define SE_UART_RX_PARITY_CFG  0x2a8
> +
> +/* SE_UART_TRANS_CFG */
> +#define UART_TX_PAR_EN BIT(0)
> +#define UART_CTS_MASK  BIT(1)
> +
> +/* SE_UART_TX_WORD_LEN */
> +#define TX_WORD_LEN_MSKGENMASK(9, 0)
> +
> +/* SE_UART_TX_STOP_BIT_LEN */
> +#define TX_STOP_BIT_LEN_MSKGENMASK(23, 0)
> +#define TX_STOP_BIT_LEN_1  0
> +#define TX_STOP_BIT_LEN_1_51
> +#define TX_STOP_BIT_LEN_2  2
> +
> +/* SE_UART_TX_TRANS_LEN */
> +#define TX_TRANS_LEN_MSK   GENMASK(23, 0)
> +
> +/* SE_UART_RX_TRANS_CFG */
> +#define UART_RX_INS_STATUS_BIT BIT(2)
> +#define UART_RX_PAR_EN BIT(3)
> +
> +/* SE_UART_RX_WORD_LEN */
> +#define RX_WORD_LEN_MASK   GENMASK(9, 0)
> +
> +/* SE_UART_RX_STALE_CNT */
> +#define RX_STALE_CNT   GENMASK(23, 0)
> +
> +/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
> +#define PAR_CALC_ENBIT(0)
> +#define PAR_MODE_MSK   GENMASK(2, 1)
> +#define PAR_MODE_SHFT  1
> +#define PAR_EVEN   0x00
> +#define PAR_ODD0x01
> +#define PAR_SPACE  0x10
> +#define PAR_MARK   0x11
> +
> +/* UART M_CMD OP codes */
> +#define UART_START_TX  0x1
> +#define UART_START_BREAK   0x4
> +#define UART_STOP_BREAK0x5
> +/* UART S_CMD OP codes */
> +#define UART_START_READ0x1
> +#define UART_PARAM 0x1
> +
> +#define UART_OVERSAMPLING  32
> +#define STALE_TIMEOUT  16
> +#define DEFAULT_BITS_PER_CHAR  10
> +#define GENI_UART_CONS_PORTS   1
> +#define DEF_FIFO_DEPTH_WORDS   16
> +#define DEF_TX_WM  2
> +#define DEF_FIFO_WIDTH_BITS32
> +#define UART_CONSOLE_RX_WM 2
> +
> +#ifdef CONFIG_CONSOLE_POLL
> +#define RX_BYTES_PW 1
> +#else
> +#define RX_BYTES_PW 4
> +#endif
> +
> +struct qcom_geni_serial_port {
> +   struct uart_port uport;
> +   struct geni_se se;
> +   char name[20];
> +   u32 tx_fifo_depth;
> +   u32 tx_fifo_width;
> +   u32 rx_fifo_depth;
> +   u32 tx_wm;
> +   u32 rx_wm;
> +   u32 rx_rfr;
> +   int xfer_mode;

Can this be an enum?

> +   bool port_setup;

Maybe just 'setup'? Port is in the type already.

> +   int (*handle_rx)(struct uart_port *uport,
> +   u32 rx_bytes, bool drop_rx);

s/rx_bytes/bytes/
s/drop_rx/drop/

> +   unsigned int xmit_size;
> +   unsigned int cur_baud;

s/cur//

> +   unsigned int tx_bytes_pw;
> +   unsigned int rx_bytes_pw;
> +};
> +
> +static const struct uart_ops qcom_geni_serial_pops;
> +static struct uart_driver qcom_geni_console_driver;
> +static int handle_rx_console(struct uart_port *uport,
> +   u32 rx_bytes, bool drop_rx);

s/rx_bytes/bytes/
s/drop_rx/drop/

> +static unsigned int qcom_geni_serial_tx_empty(struct uart_port *port);
> +static bool qcom_geni_serial_poll_bit(struct uart_port *uport,
> +

Re: [PATCH] xfs: Change URL for the project in xfs.txt

2018-03-02 Thread Eric Sandeen 


On 3/2/18 3:57 PM, Dave Chinner wrote:
> On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote:
>> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote:
>>> The oss.sgi.com doesn't exist any more.
>>> Change it to current project URL, https://xfs.wiki.kernel.org/
>>>
>>> Signed-off-by: Masanari Iida 
>>> ---
>>>  Documentation/filesystems/xfs.txt | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/filesystems/xfs.txt 
>>> b/Documentation/filesystems/xfs.txt
>>> index 3b9b5c149f32..4d9ff0a7f8e1 100644
>>> --- a/Documentation/filesystems/xfs.txt
>>> +++ b/Documentation/filesystems/xfs.txt
>>> @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive 
>>> use of
>>>  Btrees (directories, extents, free space) to aid both performance
>>>  and scalability.
>>>  
>>> -Refer to the documentation at http://oss.sgi.com/projects/xfs/
>>> +Refer to the documentation at https://xfs.wiki.kernel.org/
> 
> Did I miss a memo?

About which part, the loss of oss.sgi or the addition of the kernel.org wiki?

The kernel.org wiki is pretty bare though.  OTOH xfs.org is a bit less
official.  We really need to resolve this issue.

-Eric

> Cheers,
> 
> Dave.
> 
--
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] xfs: Change URL for the project in xfs.txt

2018-03-02 Thread Dave Chinner 
On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote:
> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote:
> > The oss.sgi.com doesn't exist any more.
> > Change it to current project URL, https://xfs.wiki.kernel.org/
> > 
> > Signed-off-by: Masanari Iida 
> > ---
> >  Documentation/filesystems/xfs.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/filesystems/xfs.txt 
> > b/Documentation/filesystems/xfs.txt
> > index 3b9b5c149f32..4d9ff0a7f8e1 100644
> > --- a/Documentation/filesystems/xfs.txt
> > +++ b/Documentation/filesystems/xfs.txt
> > @@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive 
> > use of
> >  Btrees (directories, extents, free space) to aid both performance
> >  and scalability.
> >  
> > -Refer to the documentation at http://oss.sgi.com/projects/xfs/
> > +Refer to the documentation at https://xfs.wiki.kernel.org/

Did I miss a memo?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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 2/4] soc: qcom: Add GENI based QUP Wrapper driver

2018-03-02 Thread Stephen Boyd 
Quoting Karthikeyan Ramasubramanian (2018-02-27 17:38:07)
> This driver manages the Generic Interface (GENI) firmware based Qualcomm
> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
> programmable module composed of multiple Serial Engines (SE) and supports
> a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
> driver also enables managing the serial interface independent aspects of
> Serial Engines.
> 
> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Girish Mahadevan 
> ---
>  drivers/soc/qcom/Kconfig|   9 +
>  drivers/soc/qcom/Makefile   |   1 +
>  drivers/soc/qcom/qcom-geni-se.c | 971 
> 
>  include/linux/qcom-geni-se.h| 247 ++
>  4 files changed, 1228 insertions(+)
>  create mode 100644 drivers/soc/qcom/qcom-geni-se.c
>  create mode 100644 include/linux/qcom-geni-se.h
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index e050eb8..cc460d0 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -3,6 +3,15 @@
>  #
>  menu "Qualcomm SoC drivers"
>  
> +config QCOM_GENI_SE
> +   tristate "QCOM GENI Serial Engine Driver"
> +   depends on ARCH_QCOM

Add || COMPILE_TEST?

> +   help
> + This module is used to manage Generic Interface (GENI) firmware 
> based

s/module/driver?

> + Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
> + module is also used to manage the common aspects of multiple Serial
s/module/driver?

> + Engines present in the QUP.
> +
>  config QCOM_GLINK_SSR
> tristate "Qualcomm Glink SSR driver"
> depends on RPMSG
> diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
> new file mode 100644
> index 000..61335b8
> --- /dev/null
> +++ b/drivers/soc/qcom/qcom-geni-se.c
> @@ -0,0 +1,971 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

#include 

> +
> +/**
> + * DOC: Overview
> + *
> + * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced
> + * to manage GENI firmware based Qualcomm Universal Peripheral (QUP) Wrapper
> + * controller. QUP Wrapper is designed to support various serial bus 
> protocols
> + * like UART, SPI, I2C, I3C, etc.
> + */
> +
> +/**
> + * DOC: Hardware description
> + *
> + * GENI based QUP is a highly-flexible and programmable module for supporting
> + * a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single
> + * QUP module can provide upto 8 Serial Interfaces, using its internal
> + * Serial Engines. The actual configuration is determined by the target
> + * platform configuration. The protocol supported by each interface is
> + * determined by the firmware loaded to the Serial Engine. Each SE consists
> + * of a DMA Engine and GENI sub modules which enable Serial Engines to
> + * support FIFO and DMA modes of operation.
> + *
> + *
> + *  +-+
> + *  |QUP Wrapper  |
> + *  | ++  |
> + *   --QUP & SE Clocks--> | Serial Engine N|  +-IO-->
> + *  | | ...|  | Interface
> + *   <---Clock Perf.+++---+|  |
> + * State Interface  || Serial Engine 1||  |
> + *  ||||  |
> + *  ||||  |
> + *   |||  |
> + *  ||++  |
> + *  |||   |
> + *  |||   |
> + *   <--SE IRQ--+++   |
> + *  | |
> + *  +-+
> + *
> + * Figure 1: GENI based QUP Wrapper

The code talks about primary and secondary sequencers, but this hardware
description doesn't talk about it. Can you add some more information
here about that aspect too?

> + */
> +
> +/**
> + * DOC: Software description
> + *
> + * GENI SE Wrapper driver is structured into 2 parts:
> + *
> + * geni_wrapper represents QUP Wrapper controller. This part of the driver
> + * manages QUP Wrapper information such as hardware version, clock
> + * performance table that is common to all the internal Serial Engines.
> + *
> + * geni_se represents Serial

Re: [PATCH v3] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Jani Nikula 
On Fri, 02 Mar 2018, Matthew Wilcox  wrote:
> From: Matthew Wilcox 
>
> Sphinx 1.7 removed sphinx.util.compat.Directive so people
> who have upgraded cannot build the documentation.  Switch to
> docutils.parsers.rst.Directive which has been available since
> docutils 0.5 released in 2009.
>
> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
> Co-developed-by: Takashi Iwai 
> Signed-off-by: Matthew Wilcox 

I think this is the best approach.

FWIW,

Acked-by: Jani Nikula 

>
> diff --git a/Documentation/sphinx/kerneldoc.py 
> b/Documentation/sphinx/kerneldoc.py
> index 39aa9e8697cc..fbedcc39460b 100644
> --- a/Documentation/sphinx/kerneldoc.py
> +++ b/Documentation/sphinx/kerneldoc.py
> @@ -36,8 +36,7 @@ import glob
>  
>  from docutils import nodes, statemachine
>  from docutils.statemachine import ViewList
> -from docutils.parsers.rst import directives
> -from sphinx.util.compat import Directive
> +from docutils.parsers.rst import directives, Directive
>  from sphinx.ext.autodoc import AutodocReporter
>  
>  __version__  = '1.0'

-- 
Jani Nikula, Intel Open Source Technology Center
--
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 v3] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Matthew Wilcox 
From: Matthew Wilcox 

Sphinx 1.7 removed sphinx.util.compat.Directive so people
who have upgraded cannot build the documentation.  Switch to
docutils.parsers.rst.Directive which has been available since
docutils 0.5 released in 2009.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
Co-developed-by: Takashi Iwai 
Signed-off-by: Matthew Wilcox 

diff --git a/Documentation/sphinx/kerneldoc.py 
b/Documentation/sphinx/kerneldoc.py
index 39aa9e8697cc..fbedcc39460b 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -36,8 +36,7 @@ import glob
 
 from docutils import nodes, statemachine
 from docutils.statemachine import ViewList
-from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+from docutils.parsers.rst import directives, Directive
 from sphinx.ext.autodoc import AutodocReporter
 
 __version__  = '1.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 v2] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Matthew Wilcox 
On Fri, Mar 02, 2018 at 08:42:54AM -0800, Matthew Wilcox wrote:
> On Fri, Mar 02, 2018 at 06:01:50PM +0200, Jani Nikula wrote:
> > On Fri, 02 Mar 2018, Takashi Iwai  wrote:
> > > The sphinx.util.compat for Directive stuff was deprecated in the
> > > recent Sphinx version, and now we get a build error.
> > >
> > > Let's import from the new place, docutils.parsers.rst, while keeping
> > > the old sphinx.util.compat as fallback.
> > >
> > > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
> > > Signed-off-by: Takashi Iwai 
> > > ---
> > > v1->v2: Change the fallback order as Matthew suggested, the new one at 
> > > first
> > 
> > So this crossed my mind as well... and then I thought it'll probably
> > succeed on older Sphinx, and the fallback is not needed. The question
> > is, are these equal? Can we just import from docutils.parsers.rst?
> 
> I found a github page which implies that docutils.parsers.rst.Directive
> was added 12 years ago (!) so we're probably safe to rely on it:
> 
> https://github.com/docutils-mirror/docutils/commit/9649abee47b4ce4db51be1d90fcb1fb500fa78b3
> 
> Again, I'm no pythonista, so I may have muddled this.

I spent some time delving through the Sphinx codebase.  The compat
version was added so you could use Directive with docutils 0.4 onwards.
docutils 0.5 onwards has Directive.  So as long as we're comfortable
mandating docutils from 2009, we're fine ;-)
--
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] Input: trackpoint: document sysfs interface

2018-03-02 Thread Aishwarya Pant 
Descriptions have been collected from git commit logs, code commits and
the TrackPoint System Version 4.0 Engineering Specification.

Signed-off-by: Aishwarya Pant 
---
 .../ABI/testing/sysfs-devices-platform-trackpoint  | 115 +
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-trackpoint

diff --git a/Documentation/ABI/testing/sysfs-devices-platform-trackpoint 
b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
new file mode 100644
index ..df11901a6b3d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-trackpoint
@@ -0,0 +1,115 @@
+What:  /sys/devices/platform/i8042/.../sensitivity
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Trackpoint sensitivity.
+
+What:  /sys/devices/platform/i8042/.../intertia
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Negative inertia factor. High values cause the cursor to
+   snap backward when the trackpoint is released.
+
+What:  /sys/devices/platform/i8042/.../reach
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Backup range for z-axis press.
+
+What:  /sys/devices/platform/i8042/.../draghys
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) The drag hysteresis controls how hard it is to drag with
+   z-axis pressed.
+
+What:  /sys/devices/platform/i8042/.../mindrag
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Minimum amount of force needed to trigger dragging.
+
+What:  /sys/devices/platform/i8042/.../speed
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Speed of the trackpoint cursor.
+
+What:  /sys/devices/platform/i8042/.../thresh
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Minimum value for z-axis force required to trigger a press
+   or release, relative to the running average.
+
+What:  /sys/devices/platform/i8042/.../upthresh
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) The offset from the running average required to generate a
+   select (click) on z-axis on release.
+
+What:  /sys/devices/platform/i8042/.../ztime
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) This attribute determines how sharp a press has to be in
+   order to be recognized.
+
+What:  /sys/devices/platform/i8042/.../jenks
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Minimum curvature in degrees required to generate a double
+   click without a release.
+
+What:  /sys/devices/platform/i8042/.../skipback
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) When the skipback bit is set, backup cursor movement during
+   releases from drags will be suppressed. The default value for
+   this bit is 0.
+
+What:  /sys/devices/platform/i8042/.../ext_dev
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Disable (0) or enable (1) external pointing device.
+
+What:  /sys/devices/platform/i8042/.../press_to_select
+Date:  Aug, 2005
+KernelVersion: 2.6.14
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) Writing a value of 1 to this file will enable the Press to
+   Select functions like tapping the control stick to simulate a
+   left click, and writing 0 will disable it.
+
+What:  /sys/devices/platform/i8042/.../drift_time
+Date:  Dec, 2014
+KernelVersion: 3.19
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) This parameter controls the period of time to test for a
+   ‘hands off’ condition (i.e. when no force is applied) before a
+   drift (noise) calibration occurs.
+
+   IBM Trackpoints have a feature to compensate for drift by
+   recalibrating themselves periodically. By default, if for 0.5
+   seconds there is no change in position, it's used as the new
+   zero. This duration is too low. Often, the calibration happens
+   when the

Re: [PATCH v2] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Matthew Wilcox 
On Fri, Mar 02, 2018 at 06:01:50PM +0200, Jani Nikula wrote:
> On Fri, 02 Mar 2018, Takashi Iwai  wrote:
> > The sphinx.util.compat for Directive stuff was deprecated in the
> > recent Sphinx version, and now we get a build error.
> >
> > Let's import from the new place, docutils.parsers.rst, while keeping
> > the old sphinx.util.compat as fallback.
> >
> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
> > Signed-off-by: Takashi Iwai 
> > ---
> > v1->v2: Change the fallback order as Matthew suggested, the new one at first
> 
> So this crossed my mind as well... and then I thought it'll probably
> succeed on older Sphinx, and the fallback is not needed. The question
> is, are these equal? Can we just import from docutils.parsers.rst?

I found a github page which implies that docutils.parsers.rst.Directive
was added 12 years ago (!) so we're probably safe to rely on it:

https://github.com/docutils-mirror/docutils/commit/9649abee47b4ce4db51be1d90fcb1fb500fa78b3

Again, I'm no pythonista, so I may have muddled this.
--
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] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Matthew Wilcox 
On Fri, Mar 02, 2018 at 04:28:31PM +0100, Takashi Iwai wrote:
>  from docutils.parsers.rst import directives
> -from sphinx.util.compat import Directive
> +try:
> +from docutils.parsers.rst import directives, Directive

We also don't need 'directives' on this line as it was imported on the
previous line.

> +except ImportError:
> +from sphinx.util.compat import Directive
>  from sphinx.ext.autodoc import AutodocReporter
>  
>  __version__  = '1.0'

Here's what I tested on Debian:

+++ b/Documentation/sphinx/kerneldoc.py
@@ -37,7 +37,10 @@ import glob
 from docutils import nodes, statemachine
 from docutils.statemachine import ViewList
 from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+try:
+from docutils.parsers.rst import Directive
+except ImportError:
+from sphinx.util.compat import Directive
 from sphinx.ext.autodoc import AutodocReporter
 
 __version__  = '1.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 v2] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Jani Nikula 
On Fri, 02 Mar 2018, Takashi Iwai  wrote:
> The sphinx.util.compat for Directive stuff was deprecated in the
> recent Sphinx version, and now we get a build error.
>
> Let's import from the new place, docutils.parsers.rst, while keeping
> the old sphinx.util.compat as fallback.
>
> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
> Signed-off-by: Takashi Iwai 
> ---
> v1->v2: Change the fallback order as Matthew suggested, the new one at first

So this crossed my mind as well... and then I thought it'll probably
succeed on older Sphinx, and the fallback is not needed. The question
is, are these equal? Can we just import from docutils.parsers.rst?

I'm sorry I don't have the time to find the answers to these questions
as well. :(

BR,
Jani.


>
>  Documentation/sphinx/kerneldoc.py | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/sphinx/kerneldoc.py 
> b/Documentation/sphinx/kerneldoc.py
> index 39aa9e8697cc..34396976eb0a 100644
> --- a/Documentation/sphinx/kerneldoc.py
> +++ b/Documentation/sphinx/kerneldoc.py
> @@ -37,7 +37,10 @@ import glob
>  from docutils import nodes, statemachine
>  from docutils.statemachine import ViewList
>  from docutils.parsers.rst import directives
> -from sphinx.util.compat import Directive
> +try:
> +from docutils.parsers.rst import directives, Directive
> +except ImportError:
> +from sphinx.util.compat import Directive
>  from sphinx.ext.autodoc import AutodocReporter
>  
>  __version__  = '1.0'

-- 
Jani Nikula, Intel Open Source Technology Center
--
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/sphinx: Fix Directive import error

2018-03-02 Thread Takashi Iwai 
The sphinx.util.compat for Directive stuff was deprecated in the
recent Sphinx version, and now we get a build error.

Let's import from the new place, docutils.parsers.rst, while keeping
the old sphinx.util.compat as fallback.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
Signed-off-by: Takashi Iwai 
---
v1->v2: Change the fallback order as Matthew suggested, the new one at first

 Documentation/sphinx/kerneldoc.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/sphinx/kerneldoc.py 
b/Documentation/sphinx/kerneldoc.py
index 39aa9e8697cc..34396976eb0a 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -37,7 +37,10 @@ import glob
 from docutils import nodes, statemachine
 from docutils.statemachine import ViewList
 from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+try:
+from docutils.parsers.rst import directives, Directive
+except ImportError:
+from sphinx.util.compat import Directive
 from sphinx.ext.autodoc import AutodocReporter
 
 __version__  = '1.0'
-- 
2.16.2

--
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] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Jonathan Corbet 
On Fri, 02 Mar 2018 15:55:06 +0100
Takashi Iwai  wrote:

> Jon, would you like me resending the patch?  Or it's trivial enough as
> you can fix in place.

If you can resend that would be great - one less thing for me to have to
squeeze in :)

Thanks,

jon
--
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] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Takashi Iwai 
On Fri, 02 Mar 2018 15:50:55 +0100,
Matthew Wilcox wrote:
> 
> On Fri, Mar 02, 2018 at 12:49:03PM +0100, Takashi Iwai wrote:
> > I'm no expert of sphinx nor python, so something might be wrong.
> > Please check it.
> 
> I'm also not a pythonista, but ...
> 
> > --- a/Documentation/sphinx/kerneldoc.py
> > +++ b/Documentation/sphinx/kerneldoc.py
> > @@ -37,7 +37,10 @@ import glob
> >  from docutils import nodes, statemachine
> >  from docutils.statemachine import ViewList
> >  from docutils.parsers.rst import directives
> > -from sphinx.util.compat import Directive
> > +try:
> > +from sphinx.util.compat import Directive
> > +except ImportError:
> > +from docutils.parsers.rst import directives, Directive
> 
> It seems to me the previous line already imported
> docutils.parsers.rst.directives, and we should probably prefer the newer
> parser even with Sphinx 1.6, so I would think this would work better:
> 
> -from sphinx.util.compat import Directive
> +try:
> +from docutils.parsers.rst import Directive
> +except ImportError:
> +from sphinx.util.compat import Directive
> 
> (it works on Debian with Sphinx 1.6.7)

Makes more sense, yes.

Jon, would you like me resending the patch?  Or it's trivial enough as
you can fix in place.


thanks,

Takashi
--
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: kernel-doc unbuildable with sphinx 1.7

2018-03-02 Thread Jonathan Corbet 
On Fri, 02 Mar 2018 15:44:45 +0100
Takashi Iwai  wrote:

> Sure, just waited for the feedback from Jon :)

I want to try it with both old and new Sphinx, of course, but will have a
hard time doing it today - on the road all day.  But it looks reasonable
at a first glance; I'll try to get it into -rc4 (and -stable, I guess) if
I can.

Thanks,

jon
--
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] Documentation/sphinx: Fix Directive import error

2018-03-02 Thread Matthew Wilcox 
On Fri, Mar 02, 2018 at 12:49:03PM +0100, Takashi Iwai wrote:
> I'm no expert of sphinx nor python, so something might be wrong.
> Please check it.

I'm also not a pythonista, but ...

> --- a/Documentation/sphinx/kerneldoc.py
> +++ b/Documentation/sphinx/kerneldoc.py
> @@ -37,7 +37,10 @@ import glob
>  from docutils import nodes, statemachine
>  from docutils.statemachine import ViewList
>  from docutils.parsers.rst import directives
> -from sphinx.util.compat import Directive
> +try:
> +from sphinx.util.compat import Directive
> +except ImportError:
> +from docutils.parsers.rst import directives, Directive

It seems to me the previous line already imported
docutils.parsers.rst.directives, and we should probably prefer the newer
parser even with Sphinx 1.6, so I would think this would work better:

-from sphinx.util.compat import Directive
+try:
+from docutils.parsers.rst import Directive
+except ImportError:
+from sphinx.util.compat import Directive

(it works on Debian with Sphinx 1.6.7)

--
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: kernel-doc unbuildable with sphinx 1.7

2018-03-02 Thread Takashi Iwai 
On Fri, 02 Mar 2018 15:40:37 +0100,
Jiri Slaby wrote:
> 
> On 03/02/2018, 03:34 PM, Jonathan Corbet wrote:
> > I got a patch from Takashi this very morning for that problem; I guess
> > I'll have to fast-track it Linusward.
> 
> Oh, thanks!
> 
> P.S.: Takashi, could you push it to our master & stable branches?

Sure, just waited for the feedback from Jon :)


Takashi
--
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: kernel-doc unbuildable with sphinx 1.7

2018-03-02 Thread Jiri Slaby 
On 03/02/2018, 03:34 PM, Jonathan Corbet wrote:
> I got a patch from Takashi this very morning for that problem; I guess
> I'll have to fast-track it Linusward.

Oh, thanks!

P.S.: Takashi, could you push it to our master & stable branches?

-- 
js
suse labs
--
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: kernel-doc unbuildable with sphinx 1.7

2018-03-02 Thread Jonathan Corbet 
On Fri, 2 Mar 2018 15:10:14 +0100
Jiri Slaby  wrote:

> in openSUSE, sphinx was updated to 1.7.1 and kernel-doc cannot be built
> since that time:
> Running Sphinx v1.7.1
> 
> Extension error:
> Could not import extension kerneldoc (exception: cannot import name
> 'Directive')
> 
> It is because sphinx.util.compat.* was removed from sphinx in 1.7 since
> it was deprecated for a long time:
> "sphinx.util.compat.%s is deprecated and will be removed "
>"in Sphinx 1.7, please use docutils' instead."
> 
> 
> Could you fix that up? python is not my favourite interpreter so fixing
> it myself is not feasible on my side.

I got a patch from Takashi this very morning for that problem; I guess
I'll have to fast-track it Linusward.

Thanks,

jon
--
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

kernel-doc unbuildable with sphinx 1.7

2018-03-02 Thread Jiri Slaby 
Hi,

in openSUSE, sphinx was updated to 1.7.1 and kernel-doc cannot be built
since that time:
Running Sphinx v1.7.1

Extension error:
Could not import extension kerneldoc (exception: cannot import name
'Directive')

It is because sphinx.util.compat.* was removed from sphinx in 1.7 since
it was deprecated for a long time:
"sphinx.util.compat.%s is deprecated and will be removed "
   "in Sphinx 1.7, please use docutils' instead."


Could you fix that up? python is not my favourite interpreter so fixing
it myself is not feasible on my side.

thanks,
-- 
js
suse labs
--
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] xfs: Change URL for the project in xfs.txt

2018-03-02 Thread Masanari Iida 
The oss.sgi.com doesn't exist any more.
Change it to current project URL, https://xfs.wiki.kernel.org/

Signed-off-by: Masanari Iida 
---
 Documentation/filesystems/xfs.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/xfs.txt 
b/Documentation/filesystems/xfs.txt
index 3b9b5c149f32..4d9ff0a7f8e1 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -9,7 +9,7 @@ variable block sizes, is extent based, and makes extensive use 
of
 Btrees (directories, extents, free space) to aid both performance
 and scalability.
 
-Refer to the documentation at http://oss.sgi.com/projects/xfs/
+Refer to the documentation at https://xfs.wiki.kernel.org/
 for further details.  This implementation is on-disk compatible
 with the IRIX version of XFS.
 
-- 
2.16.2.345.g7e31236f652a

--
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] HID: logitech-hidpp: document sysfs interface

2018-03-02 Thread Aishwarya Pant 
Descriptions have been collected from git commit logs.

Signed-off-by: Aishwarya Pant 
---
 .../ABI/testing/sysfs-driver-hid-logitech-hidpp   | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp

diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp 
b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp
new file mode 100644
index ..d8f831f2d6b5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-hidpp
@@ -0,0 +1,19 @@
+What:  /sys/bus/hid/drivers/logitech-hidpp-device//range
+Date:  Jan, 2016
+KernelVersion: 4.6
+Contact:   linux-in...@vger.kernel.org
+Description:
+   (RW) This attribute controls the amount of 'turn' permitted in
+   Logitech G920 wheel. Reading from the file shows the current
+   range of the steering wheel. Writing a value within the min and
+   max boundary sets the range of the wheel.
+
+What:  
/sys/bus/hid/drivers/logitech-hidpp-device//builtin_power_supply
+Date:  Apr, 2017
+KernelVersion: 4.12
+Contact:   linux-in...@vger.kernel.org
+Description:
+   Presence of this file indicates that HID++ driver is capable of
+   handling battery properties in the kernel. This way, upower can
+   add a udev rule to decide whether or not it should use the
+   internal unifying support or the generic kernel one.
-- 
2.16.2

--
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/sphinx: Fix Directive import error

2018-03-02 Thread Takashi Iwai 
The sphinx.util.compat Directive stuff was deprecated in the recent
Sphinx version, and now we get a build error.

Let's take a fallback to the newer one, from docutils.parsers.rst.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1083694
Signed-off-by: Takashi Iwai 
---

I'm no expert of sphinx nor python, so something might be wrong.
Please check it.

--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -37,7 +37,10 @@ import glob
 from docutils import nodes, statemachine
 from docutils.statemachine import ViewList
 from docutils.parsers.rst import directives
-from sphinx.util.compat import Directive
+try:
+from sphinx.util.compat import Directive
+except ImportError:
+from docutils.parsers.rst import directives, Directive
 from sphinx.ext.autodoc import AutodocReporter
 
 __version__  = '1.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 00/23] kconfig: move compiler capability tests to Kconfig

2018-03-02 Thread Ulf Magnusson 
On Fri, Mar 02, 2018 at 02:50:39PM +0900, Masahiro Yamada wrote:
> 2018-02-22 6:39 GMT+09:00 Ulf Magnusson :
> > On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> >> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann :
> >> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> >> >  wrote:
> >> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann :
> >> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> >> >>>  wrote:
> >>  2018-02-20 0:18 GMT+09:00 Ulf Magnusson :
> >> >>
> >> >> Let me clarify my concern.
> >> >>
> >> >> When we test the compiler flag, is there a case
> >> >> where a particular flag depends on -m{32,64} ?
> >> >>
> >> >> For example, is there a compiler that supports -fstack-protector
> >> >> for 64bit mode, but unsupports it for 32bit mode?
> >> >>
> >> >>   $(cc-option -m32) ->  y
> >> >>   $(cc-option -m64) ->  y
> >> >>   $(cc-option -fstack-protector)->  y
> >> >>   $(cc-option -m32 -fstack-protector)   ->  n
> >> >>   $(cc-option -m64 -fstack-protector)   ->  y
> >> >>
> >> >> I guess this is unlikely to happen,
> >> >> but I am not whether it is zero possibility.
> >> >>
> >> >> If this could happen,
> >> >> $(cc-option ) must be evaluated together with
> >> >> correct bi-arch option (either -m32 or -m64).
> >> >>
> >> >>
> >> >> Currently, -m32/-m64 is specified in Makefile,
> >> >> but we are moving compiler tests to Kconfig
> >> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> >> >
> >> > I don't think it can happen for this particular combination (stack 
> >> > protector
> >> > and word size), but I'm sure we'll eventually run into options that
> >> > need to be tested in combination. For the current CFLAGS_KERNEL
> >> > setting, we definitely have the case of needing the variables to be
> >> > evaluated in a specific order.
> >> >
> >>
> >>
> >>
> >>
> >> I was thinking of how we can handle complex cases
> >> in the current approach.
> >>
> >>
> >>
> >> (Case 1)
> >>
> >> Compiler flag -foo and -bar interacts, so
> >> we also need to check the combination of the two.
> >>
> >>
> >> config CC_HAS_FOO
> >> def_bool $(cc-option -foo)
> >>
> >> config CC_HAS_BAR
> >> def_bool $(cc-option -bar)
> >>
> >> config CC_HAS_FOO_WITH_BAR
> >> def_bool $(cc-option -foo -bar)
> >>
> >>
> >>
> >> (Case 2)
> >> Compiler flag -foo is sensitive to word-size.
> >> So, we need to test this option together with -m32/-m64.
> >> User can toggle CONFIG_64BIT, like i386/x86_64.
> >>
> >>
> >> config CC_NEEDS_M64
> >>   def_bool $(cc-option -m64) && 64BIT
> >>
> >> config CC_NEEDS_M32
> >>   def_bool $(cc-option -m32) && !64BIT
> >>
> >> config CC_HAS_FOO
> >>  bool
> >>  default $(cc-option -m64 -foo) if CC_NEEDS_M64
> >>  default $(cc-option -m32 -foo) if CC_NEEDS_M32
> >>  default $(cc-option -foo)
> >>
> >>
> >>
> >> (Case 3)
> >> Compiler flag -foo is sensitive to endian-ness.
> >>
> >>
> >> config CC_NEEDS_BIG_ENDIAN
> >>   def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
> >>
> >> config CC_NEEDS_LITTLE_ENDIAN
> >>   def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
> >>
> >> config CC_HAS_FOO
> >>  bool
> >>  default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> >>  default $(cc-option -mlittle-endian -foo) if 
> >> CC_NEEDS_LITTLE_ENDIAN
> >>  default $(cc-option -foo)
> >>
> >>
> >>
> >>
> >> Hmm, I think I can implement those somehow.
> >> But, I hope we do not have many instances like this...
> >>
> >>
> >> If you know more naive cases, please share your knowledge.
> >>
> >> Thanks!
> >>
> >>
> >> --
> >> Best Regards
> >> Masahiro Yamada
> >
> > Would get pretty bad if a test needs to consider multiple symbols.
> > Exponential explosion there...
> >
> >
> > I thought some more about the implementation of dynamic (post-parsing)
> > functions to see how bad it would get with the current implementation.
> >
> > Some background on how things work now:
> >
> >   1. All expression operands in Kconfig are symbols.
> >
> >   2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
> >  you symbols with those strings as names and S_UNKNOWN type (because
> >  they act like references to undefined symbols).
> >
> >   3. For "foo-$(fn foo)", you also get a symbol with that string as its
> >  name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
> >
> >   4. Symbols with S_UNKNOWN type get their name as their string value,
> >  and the tristate value n.
> >
> > So, if you do string expansion on the names of symbols with S_UNKNOWN
> > type in sym_calc_value(), you're almost there with the current
> > implementation, except for the tristate case.
> >
> > Maybe you could set the tristate value of S_UNKNOWN symbols depending on
> >

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

2018-03-02 Thread Claudiu Beznea 


On 28.02.2018 22:04, Jani Nikula wrote:
> On Wed, 28 Feb 2018, Thierry Reding  wrote:
>> Anyone that needs something other than normal mode should use the new
>> atomic PWM API.
> 
> At the risk of revealing my true ignorance, what is the new atomic PWM
> API? Where? Examples of how one would convert old code over to the new
> API?
As far as I know, the old PWM core code uses config(), set_polarity(),
enable(), disable() methods of driver, registered as pwm_ops:
struct pwm_ops {

int (*request)(struct pwm_chip *chip, struct pwm_device *pwm);

void (*free)(struct pwm_chip *chip, struct pwm_device *pwm);

int (*config)(struct pwm_chip *chip, struct pwm_device *pwm,

  int duty_ns, int period_ns);

int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm,

enum pwm_polarity polarity);

int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm,

   struct pwm_capture *result, unsigned long timeout);

int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);

void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);

int (*apply)(struct pwm_chip *chip, struct pwm_device *pwm,

 struct pwm_state *state);

void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,

  struct pwm_state *state);

#ifdef CONFIG_DEBUG_FS

void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);

#endif

struct module *owner;

};


to do settings on hardware. In order to so settings on a PWM the users
should have been follow the below steps:
->config()
->set_polarity()
->enable()
Moreover, if the PWM was previously enabled it should have been first
disable and then to follow the above steps in order to apply a new settings
on hardware.
The driver should have been provide, at probe, all the above function:
->config(), ->set_polarity(), ->disable(), ->enable(), function that were
used by PWM core.

Now, having atomic PWM, the driver should provide one function to PWM core,
which is ->apply() function. Every PWM has a state associated, which keeps
the period, duty cycle, polarity and enable/disable status. The driver's
->apply() function takes as argument the state that should be applied and
it takes care of applying this new state directly without asking user to
call ->disable(), then ->config()/->set_polarity(), then ->enable() to
apply new hardware settings.

The PWM consumer could set a new state for PWM it uses, using
pwm_apply_state(pwm, new_state);

Regarding the models to switch on atomic PWM, on the controller side you
can check for drivers that registers apply function at probe time.
Regarding the PWM users, you can look for pwm_apply_state()
(drivers/hwmon/pwm-fan.c or drivers/input/misc/pwm-beeper.c are some examples).

Thierry, please correct me if I'm wrong.

Thank you,
Claudiu Beznea

> 
> BR,
> Jani.
> 
--
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/10] pwm: add PWM mode to pwm_config()

2018-03-02 Thread Claudiu Beznea 


On 28.02.2018 21:44, Thierry Reding wrote:
> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
>> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
>> were adapted to this change.
>>
>> Signed-off-by: Claudiu Beznea 
>> ---
>>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>>  drivers/bus/ts-nbus.c|  2 +-
>>  drivers/clk/clk-pwm.c|  3 ++-
>>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>>  drivers/hwmon/pwm-fan.c  |  2 +-
>>  drivers/input/misc/max77693-haptic.c |  2 +-
>>  drivers/input/misc/max8997_haptic.c  |  6 +-
>>  drivers/leds/leds-pwm.c  |  5 -
>>  drivers/media/rc/ir-rx51.c   |  5 -
>>  drivers/media/rc/pwm-ir-tx.c |  5 -
>>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>>  drivers/video/backlight/lp8788_bl.c  |  5 -
>>  drivers/video/backlight/pwm_bl.c | 11 +--
>>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>>  include/linux/pwm.h  |  6 --
>>  16 files changed, 70 insertions(+), 21 deletions(-)
> 
> I don't think it makes sense to leak mode support into the legacy API.
> The pwm_config() function is considered legacy
I missed this aspect.

 and should eventually go
> away. As such it doesn't make sense to integrate a new feature such as
> PWM modes into it. 
Agree.

All users of pwm_config() assume normal mode, and
> that's what pwm_config() should provide.
Agree.

> 
> Anyone that needs something other than normal mode should use the new
> atomic PWM API.
Agree.

> 
> Thierry
> 
--
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/23] kconfig: move compiler capability tests to Kconfig

2018-03-02 Thread Ulf Magnusson 
On Fri, Mar 02, 2018 at 10:03:26AM +0100, Ulf Magnusson wrote:
> On Fri, Mar 02, 2018 at 02:50:39PM +0900, Masahiro Yamada wrote:
> > 2018-02-22 6:39 GMT+09:00 Ulf Magnusson :
> > > On Wed, Feb 21, 2018 at 09:57:03PM +0900, Masahiro Yamada wrote:
> > >> 2018-02-21 19:52 GMT+09:00 Arnd Bergmann :
> > >> > On Wed, Feb 21, 2018 at 11:20 AM, Masahiro Yamada
> > >> >  wrote:
> > >> >> 2018-02-21 18:56 GMT+09:00 Arnd Bergmann :
> > >> >>> On Wed, Feb 21, 2018 at 8:38 AM, Masahiro Yamada
> > >> >>>  wrote:
> > >>  2018-02-20 0:18 GMT+09:00 Ulf Magnusson :
> > >> >>
> > >> >> Let me clarify my concern.
> > >> >>
> > >> >> When we test the compiler flag, is there a case
> > >> >> where a particular flag depends on -m{32,64} ?
> > >> >>
> > >> >> For example, is there a compiler that supports -fstack-protector
> > >> >> for 64bit mode, but unsupports it for 32bit mode?
> > >> >>
> > >> >>   $(cc-option -m32) ->  y
> > >> >>   $(cc-option -m64) ->  y
> > >> >>   $(cc-option -fstack-protector)->  y
> > >> >>   $(cc-option -m32 -fstack-protector)   ->  n
> > >> >>   $(cc-option -m64 -fstack-protector)   ->  y
> > >> >>
> > >> >> I guess this is unlikely to happen,
> > >> >> but I am not whether it is zero possibility.
> > >> >>
> > >> >> If this could happen,
> > >> >> $(cc-option ) must be evaluated together with
> > >> >> correct bi-arch option (either -m32 or -m64).
> > >> >>
> > >> >>
> > >> >> Currently, -m32/-m64 is specified in Makefile,
> > >> >> but we are moving compiler tests to Kconfig
> > >> >> and, CONFIG_64BIT can be dynamically toggled in Kconfig.
> > >> >
> > >> > I don't think it can happen for this particular combination (stack 
> > >> > protector
> > >> > and word size), but I'm sure we'll eventually run into options that
> > >> > need to be tested in combination. For the current CFLAGS_KERNEL
> > >> > setting, we definitely have the case of needing the variables to be
> > >> > evaluated in a specific order.
> > >> >
> > >>
> > >>
> > >>
> > >>
> > >> I was thinking of how we can handle complex cases
> > >> in the current approach.
> > >>
> > >>
> > >>
> > >> (Case 1)
> > >>
> > >> Compiler flag -foo and -bar interacts, so
> > >> we also need to check the combination of the two.
> > >>
> > >>
> > >> config CC_HAS_FOO
> > >> def_bool $(cc-option -foo)
> > >>
> > >> config CC_HAS_BAR
> > >> def_bool $(cc-option -bar)
> > >>
> > >> config CC_HAS_FOO_WITH_BAR
> > >> def_bool $(cc-option -foo -bar)
> > >>
> > >>
> > >>
> > >> (Case 2)
> > >> Compiler flag -foo is sensitive to word-size.
> > >> So, we need to test this option together with -m32/-m64.
> > >> User can toggle CONFIG_64BIT, like i386/x86_64.
> > >>
> > >>
> > >> config CC_NEEDS_M64
> > >>   def_bool $(cc-option -m64) && 64BIT
> > >>
> > >> config CC_NEEDS_M32
> > >>   def_bool $(cc-option -m32) && !64BIT
> > >>
> > >> config CC_HAS_FOO
> > >>  bool
> > >>  default $(cc-option -m64 -foo) if CC_NEEDS_M64
> > >>  default $(cc-option -m32 -foo) if CC_NEEDS_M32
> > >>  default $(cc-option -foo)
> > >>
> > >>
> > >>
> > >> (Case 3)
> > >> Compiler flag -foo is sensitive to endian-ness.
> > >>
> > >>
> > >> config CC_NEEDS_BIG_ENDIAN
> > >>   def_bool $(cc-option -mbig-endian) && CPU_BIG_ENDIAN
> > >>
> > >> config CC_NEEDS_LITTLE_ENDIAN
> > >>   def_bool $(cc-option -mlittle-endian) && CPU_LITTLE_ENDIAN
> > >>
> > >> config CC_HAS_FOO
> > >>  bool
> > >>  default $(cc-option -mbig-endian -foo) if CC_NEEDS_BIG_ENDIAN
> > >>  default $(cc-option -mlittle-endian -foo) if 
> > >> CC_NEEDS_LITTLE_ENDIAN
> > >>  default $(cc-option -foo)
> > >>
> > >>
> > >>
> > >>
> > >> Hmm, I think I can implement those somehow.
> > >> But, I hope we do not have many instances like this...
> > >>
> > >>
> > >> If you know more naive cases, please share your knowledge.
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> --
> > >> Best Regards
> > >> Masahiro Yamada
> > >
> > > Would get pretty bad if a test needs to consider multiple symbols.
> > > Exponential explosion there...
> > >
> > >
> > > I thought some more about the implementation of dynamic (post-parsing)
> > > functions to see how bad it would get with the current implementation.
> > >
> > > Some background on how things work now:
> > >
> > >   1. All expression operands in Kconfig are symbols.
> > >
> > >   2. Returning '$ENV' or '$(fn foo)' as a T_WORD during parsing gets
> > >  you symbols with those strings as names and S_UNKNOWN type (because
> > >  they act like references to undefined symbols).
> > >
> > >   3. For "foo-$(fn foo)", you also get a symbol with that string as its
> > >  name and S_UNKNOWN type (stored among the SYMBOL_CONST symbols)
> > >
> > >   4. Symbols with S_UNKNOWN type get