Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:24 AM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap  wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
 Hello,

 I've added incremental search for jumping directly to a symbol now.
 Regular expressions are supported as well.

 Some screenshots below:

 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png

 The last screenshot shows how things might look after you jump to a
 symbol. The jumped-to symbol wasn't visible in this case, so show-all
 mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>>
>> Enter: / (search)
>> then:  * (Bang) [this was just an unlucky typo on my part]
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
>> for regex in s.split()]
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
>> for regex in s.split()]
>>   File "/usr/lib64/python3.4/re.py", line 223, in compile
>> return _compile(pattern, flags)
>>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
>> p = sre_compile.compile(pattern, flags)
>>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
>> p = sre_parse.parse(p, flags)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
>> p = _parse_sub(source, pattern, 0)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
>> itemsappend(_parse(source, state))
>>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
>> raise error("nothing to repeat")
>> sre_constants.error: nothing to repeat
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
>> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
>> print(curses.wrapper(_menuconfig))
>>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
>> return func(stdscr, *args, **kwds)
>>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
>> _jump_to_dialog()
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
>> bad_re = e.msg
>> AttributeError: 'error' object has no attribute 'msg'
>>
>>
>>
>> --
>> ~Randy
>
> Thanks for the report!
>
> Invalid regular expressions are detected, but it looks like the 'msg'
> field of re.error was added in Python 3.5 (you have 3.4).
>
> I'll check if the 'msg' field exists and fall back to just printing
> "Invalid regular expression" otherwise. The 'msg' field just gives a
> more informative error
> ("Bad regular expression: nothing to repeat" in this case).
>
> Cheers,
> Ulf

Fixed: 
https://github.com/ulfalizer/Kconfiglib/commit/3072e7338cfc63f2f81f34d02edc34dab3d9f365

Your environment seems to have a knack for finding stuff like that.

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:24 AM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap  wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
 Hello,

 I've added incremental search for jumping directly to a symbol now.
 Regular expressions are supported as well.

 Some screenshots below:

 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png

 The last screenshot shows how things might look after you jump to a
 symbol. The jumped-to symbol wasn't visible in this case, so show-all
 mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>>
>> Enter: / (search)
>> then:  * (Bang) [this was just an unlucky typo on my part]
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
>> for regex in s.split()]
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
>> for regex in s.split()]
>>   File "/usr/lib64/python3.4/re.py", line 223, in compile
>> return _compile(pattern, flags)
>>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
>> p = sre_compile.compile(pattern, flags)
>>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
>> p = sre_parse.parse(p, flags)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
>> p = _parse_sub(source, pattern, 0)
>>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
>> itemsappend(_parse(source, state))
>>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
>> raise error("nothing to repeat")
>> sre_constants.error: nothing to repeat
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
>> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
>> print(curses.wrapper(_menuconfig))
>>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
>> return func(stdscr, *args, **kwds)
>>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
>> _jump_to_dialog()
>>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
>> bad_re = e.msg
>> AttributeError: 'error' object has no attribute 'msg'
>>
>>
>>
>> --
>> ~Randy
>
> Thanks for the report!
>
> Invalid regular expressions are detected, but it looks like the 'msg'
> field of re.error was added in Python 3.5 (you have 3.4).
>
> I'll check if the 'msg' field exists and fall back to just printing
> "Invalid regular expression" otherwise. The 'msg' field just gives a
> more informative error
> ("Bad regular expression: nothing to repeat" in this case).
>
> Cheers,
> Ulf

Fixed: 
https://github.com/ulfalizer/Kconfiglib/commit/3072e7338cfc63f2f81f34d02edc34dab3d9f365

Your environment seems to have a knack for finding stuff like that.

Cheers,
Ulf

Re: [PATCH 10/32] aio: implement IOCB_CMD_POLL

[Al Viro]

On Tue, May 15, 2018 at 09:48:11PM +0200, Christoph Hellwig wrote:
> +static ssize_t aio_poll(struct aio_kiocb *aiocb, struct iocb *iocb)
> +{
> + struct kioctx *ctx = aiocb->ki_ctx;
> + struct poll_iocb *req = >poll;
> + unsigned long flags;
> + __poll_t mask;
> +
> + /* reject any unknown events outside the normal event mask. */
> + if ((u16)iocb->aio_buf != iocb->aio_buf)
> + return -EINVAL;
> + /* reject fields that are not defined for poll */
> + if (iocb->aio_offset || iocb->aio_nbytes || iocb->aio_rw_flags)
> + return -EINVAL;
> +
> + req->events = demangle_poll(iocb->aio_buf) | POLLERR | POLLHUP;
> + req->file = fget(iocb->aio_fildes);
> + if (unlikely(!req->file))
> + return -EBADF;
> + if (!file_has_poll_mask(req->file))
> + goto out_fail;
> +
> + req->head = req->file->f_op->get_poll_head(req->file, req->events);
> + if (!req->head)
> + goto out_fail;
> + if (IS_ERR(req->head)) {
> + mask = EPOLLERR;
> + goto done;
> + }
> +
> + init_waitqueue_func_entry(>wait, aio_poll_wake);
> + aiocb->ki_cancel = aio_poll_cancel;
> +
> + spin_lock_irqsave(>ctx_lock, flags);
> + list_add_tail(>ki_list, >delayed_cancel_reqs);
> + spin_unlock(>ctx_lock);

... and io_cancel(2) comes, finds it and inhume^Wcompletes it, leaving us to...

> + spin_lock(>head->lock);

... get buggered on attempt to dereference a pointer fetched from freed and
reused object.

Re: [PATCH 10/32] aio: implement IOCB_CMD_POLL

[Al Viro]

On Tue, May 15, 2018 at 09:48:11PM +0200, Christoph Hellwig wrote:
> +static ssize_t aio_poll(struct aio_kiocb *aiocb, struct iocb *iocb)
> +{
> + struct kioctx *ctx = aiocb->ki_ctx;
> + struct poll_iocb *req = >poll;
> + unsigned long flags;
> + __poll_t mask;
> +
> + /* reject any unknown events outside the normal event mask. */
> + if ((u16)iocb->aio_buf != iocb->aio_buf)
> + return -EINVAL;
> + /* reject fields that are not defined for poll */
> + if (iocb->aio_offset || iocb->aio_nbytes || iocb->aio_rw_flags)
> + return -EINVAL;
> +
> + req->events = demangle_poll(iocb->aio_buf) | POLLERR | POLLHUP;
> + req->file = fget(iocb->aio_fildes);
> + if (unlikely(!req->file))
> + return -EBADF;
> + if (!file_has_poll_mask(req->file))
> + goto out_fail;
> +
> + req->head = req->file->f_op->get_poll_head(req->file, req->events);
> + if (!req->head)
> + goto out_fail;
> + if (IS_ERR(req->head)) {
> + mask = EPOLLERR;
> + goto done;
> + }
> +
> + init_waitqueue_func_entry(>wait, aio_poll_wake);
> + aiocb->ki_cancel = aio_poll_cancel;
> +
> + spin_lock_irqsave(>ctx_lock, flags);
> + list_add_tail(>ki_list, >delayed_cancel_reqs);
> + spin_unlock(>ctx_lock);

... and io_cancel(2) comes, finds it and inhume^Wcompletes it, leaving us to...

> + spin_lock(>head->lock);

... get buggered on attempt to dereference a pointer fetched from freed and
reused object.

Re: [PATCH 08/32] aio: replace kiocb_set_cancel_fn with a cancel_kiocb file operation

[Al Viro]

On Tue, May 15, 2018 at 09:48:09PM +0200, Christoph Hellwig wrote:

>   case -EIOCBQUEUED:
> + if (req->ki_filp->f_op->cancel_kiocb) {
> + struct aio_kiocb *iocb =
> + container_of(req, struct aio_kiocb, rw);
> + struct kioctx *ctx = iocb->ki_ctx;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>ctx_lock, flags);
> + list_add_tail(>ki_list, >active_reqs);

Use after free - that list insertion used to be done by drivers and doing
so before any ->ki_complete() calls might've happened used to be their
responsibility.  Now you've taken that to the point after ->read_iter()
(or ->write_iter()) return, so there's no way in hell to guarantee it's
not been completed (and freed) by that point.

Incidentally, none of the callers gives a damn about the difference between
0 and -EIOCBQUEUED now, so aio_rw_ret() might as well had been made void...

Re: [PATCH 08/32] aio: replace kiocb_set_cancel_fn with a cancel_kiocb file operation

[Al Viro]

On Tue, May 15, 2018 at 09:48:09PM +0200, Christoph Hellwig wrote:

>   case -EIOCBQUEUED:
> + if (req->ki_filp->f_op->cancel_kiocb) {
> + struct aio_kiocb *iocb =
> + container_of(req, struct aio_kiocb, rw);
> + struct kioctx *ctx = iocb->ki_ctx;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>ctx_lock, flags);
> + list_add_tail(>ki_list, >active_reqs);

Use after free - that list insertion used to be done by drivers and doing
so before any ->ki_complete() calls might've happened used to be their
responsibility.  Now you've taken that to the point after ->read_iter()
(or ->write_iter()) return, so there's no way in hell to guarantee it's
not been completed (and freed) by that point.

Incidentally, none of the callers gives a damn about the difference between
0 and -EIOCBQUEUED now, so aio_rw_ret() might as well had been made void...

[PATCH v2 3/5] arm64: dts: actions: Add gpio line names to Bubblegum-96 board

[Manivannan Sadhasivam]

Add gpio line names to Actions Semi S900 based Bubblegum-96 board.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++
 1 file changed, 175 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts 
b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index ff043c961d75..d0ba35df9015 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -34,3 +34,178 @@
status = "okay";
clocks = < CLK_UART5>;
 };
+
+/*
+ * GPIO name legend: proper name = the GPIO line is used as GPIO
+ * NC = not connected (pin out but not routed from the chip to
+ *  anything the board)
+ * "[PER]" = pin is muxed for [peripheral] (not GPIO)
+ * LSEC = Low Speed External Connector
+ * HSEC = High Speed External Connector
+ *
+ * Line names are taken from the schematic "Schematics Bubblegum96"
+ * version v1.0
+ *
+ * For the lines routed to the external connectors the
+ * lines are named after the 96Boards CE Specification 1.0,
+ * Appendix "Expansion Connector Signal Description".
+ *
+ * When the 96Boards naming of a line and the schematic name of
+ * the same line are in conflict, the 96Boards specification
+ * takes precedence, which means that the external UART on the
+ * LSEC is named UART0 while the schematic and SoC names this
+ * UART2. Only exception is the I2C lines for which the schematic
+ * naming has been preferred. This is only for the informational
+ * lines i.e. "[FOO]", the GPIO named lines "GPIO-A" thru "GPIO-L"
+ * are the only ones actually used for GPIO.
+ */
+
+ {
+   gpio-line-names =
+   "GPIO-A", /* GPIO_0, LSEC pin 23 */
+   "GPIO-B", /* GPIO_1, LSEC pin 24 */
+   "GPIO-C", /* GPIO_2, LSEC pin 25 */
+   "GPIO-D", /* GPIO_3, LSEC pin 26 */
+   "GPIO-E", /* GPIO_4, LSEC pin 27 */
+   "GPIO-F", /* GPIO_5, LSEC pin 28 */
+   "GPIO-G", /* GPIO_6, LSEC pin 29 */
+   "GPIO-H", /* GPIO_7, LSEC pin 30 */
+   "GPIO-I", /* GPIO_8, LSEC pin 31 */
+   "GPIO-J", /* GPIO_9, LSEC pin 32 */
+   "NC", /* GPIO_10 */
+   "NC", /* GPIO_11 */
+   "SIRQ2_1V8", /* GPIO_12 */
+   "PCM0_OUT", /* GPIO_13 */
+   "WIFI_LED", /* GPIO_14 */
+   "PCM0_SYNC", /* GPIO_15 */
+   "PCM0_CLK", /* GPIO_16 */
+   "PCM0_IN", /* GPIO_17 */
+   "BT_LED", /* GPIO_18 */
+   "LED0", /* GPIO_19 */
+   "LED1", /* GPIO_20 */
+   "JTAG_TCK", /* GPIO_21 */
+   "JTAG_TMS", /* GPIO_22 */
+   "JTAG_TDI", /* GPIO_23 */
+   "JTAG_TDO", /* GPIO_24 */
+   "[UART1_RxD]", /* GPIO_25, LSEC pin 13 */
+   "NC", /* GPIO_26 */
+   "[UART1_TxD]", /* GPIO_27, LSEC pin 11 */
+   "SD0_D0", /* GPIO_28 */
+   "SD0_D1", /* GPIO_29 */
+   "SD0_D2", /* GPIO_30 */
+   "SD0_D3", /* GPIO_31 */
+   "SD1_D0", /* GPIO_32 */
+   "SD1_D1", /* GPIO_33 */
+   "SD1_D2", /* GPIO_34 */
+   "SD1_D3", /* GPIO_35 */
+   "SD0_CMD", /* GPIO_36 */
+   "SD0_CLK", /* GPIO_37 */
+   "SD1_CMD", /* GPIO_38 */
+   "SD1_CLK", /* GPIO_39 */
+   "SPI0_SCLK", /* GPIO_40, LSEC pin 8 */
+   "SPI0_CS", /* GPIO_41, LSEC pin 12 */
+   "SPI0_DIN", /* GPIO_42, LSEC pin 10 */
+   "SPI0_DOUT", /* GPIO_43, LSEC pin 14 */
+   "I2C5_SDATA", /* GPIO_44, HSEC pin 36 */
+   "I2C5_SCLK", /* GPIO_45, HSEC pin 38 */
+   "UART0_RX", /* GPIO_46, LSEC pin 7 */
+   "UART0_TX", /* GPIO_47, LSEC pin 5 */
+   "UART0_RTSB", /* GPIO_48, LSEC pin 9 */
+   "UART0_CTSB", /* GPIO_49, LSEC pin 3 */
+   "I2C4_SCLK", /* GPIO_50, HSEC pin 32 */
+   "I2C4_SDATA", /* GPIO_51, HSEC pin 34 */
+   "I2C0_SCLK", /* GPIO_52 */
+   "I2C0_SDATA", /* GPIO_53 */
+   "I2C1_SCLK", /* GPIO_54, LSEC pin 15 */
+   "I2C1_SDATA", /* GPIO_55, LSEC pin 17 */
+   "I2C2_SCLK", /* GPIO_56, LSEC pin 19 */
+   "I2C2_SDATA", /* GPIO_57, LSEC pin 21 */
+   "CSI0_DN0", /* GPIO_58, HSEC pin 10 */
+   "CSI0_DP0", /* GPIO_59, HSEC pin 8 */
+   "CSI0_DN1", /* GPIO_60, HSEC pin 16 */
+   "CSI0_DP1", /* GPIO_61, HSEC pin 14 */
+   "CSI0_CN", /* GPIO_62, HSEC pin 4 */
+   "CSI0_CP", /* GPIO_63, HSEC pin 2 */
+   "CSI0_DN2", /* GPIO_64, HSEC pin 22 */
+   "CSI0_DP2", /* GPIO_65, HSEC pin 20 */
+   "CSI0_DN3", /* GPIO_66, HSEC pin 28 */
+   

[PATCH v2 2/5] arm64: dts: actions: Add gpio properties to pinctrl node for S900

[Manivannan Sadhasivam]

Add gpio properties to pinctrl node for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s900.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s900.dtsi 
b/arch/arm64/boot/dts/actions/s900.dtsi
index 0156483f0f4d..aa3a49b0d646 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -178,6 +178,9 @@
compatible = "actions,s900-pinctrl";
reg = <0x0 0xe01b 0x0 0x1000>;
clocks = < CLK_GPIO>;
+   gpio-controller;
+   gpio-ranges = < 0 0 146>;
+   #gpio-cells = <2>;
};
 
timer: timer@e0228000 {
-- 
2.14.1

[PATCH v2 3/5] arm64: dts: actions: Add gpio line names to Bubblegum-96 board

[Manivannan Sadhasivam]

Add gpio line names to Actions Semi S900 based Bubblegum-96 board.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++
 1 file changed, 175 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts 
b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index ff043c961d75..d0ba35df9015 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -34,3 +34,178 @@
status = "okay";
clocks = < CLK_UART5>;
 };
+
+/*
+ * GPIO name legend: proper name = the GPIO line is used as GPIO
+ * NC = not connected (pin out but not routed from the chip to
+ *  anything the board)
+ * "[PER]" = pin is muxed for [peripheral] (not GPIO)
+ * LSEC = Low Speed External Connector
+ * HSEC = High Speed External Connector
+ *
+ * Line names are taken from the schematic "Schematics Bubblegum96"
+ * version v1.0
+ *
+ * For the lines routed to the external connectors the
+ * lines are named after the 96Boards CE Specification 1.0,
+ * Appendix "Expansion Connector Signal Description".
+ *
+ * When the 96Boards naming of a line and the schematic name of
+ * the same line are in conflict, the 96Boards specification
+ * takes precedence, which means that the external UART on the
+ * LSEC is named UART0 while the schematic and SoC names this
+ * UART2. Only exception is the I2C lines for which the schematic
+ * naming has been preferred. This is only for the informational
+ * lines i.e. "[FOO]", the GPIO named lines "GPIO-A" thru "GPIO-L"
+ * are the only ones actually used for GPIO.
+ */
+
+ {
+   gpio-line-names =
+   "GPIO-A", /* GPIO_0, LSEC pin 23 */
+   "GPIO-B", /* GPIO_1, LSEC pin 24 */
+   "GPIO-C", /* GPIO_2, LSEC pin 25 */
+   "GPIO-D", /* GPIO_3, LSEC pin 26 */
+   "GPIO-E", /* GPIO_4, LSEC pin 27 */
+   "GPIO-F", /* GPIO_5, LSEC pin 28 */
+   "GPIO-G", /* GPIO_6, LSEC pin 29 */
+   "GPIO-H", /* GPIO_7, LSEC pin 30 */
+   "GPIO-I", /* GPIO_8, LSEC pin 31 */
+   "GPIO-J", /* GPIO_9, LSEC pin 32 */
+   "NC", /* GPIO_10 */
+   "NC", /* GPIO_11 */
+   "SIRQ2_1V8", /* GPIO_12 */
+   "PCM0_OUT", /* GPIO_13 */
+   "WIFI_LED", /* GPIO_14 */
+   "PCM0_SYNC", /* GPIO_15 */
+   "PCM0_CLK", /* GPIO_16 */
+   "PCM0_IN", /* GPIO_17 */
+   "BT_LED", /* GPIO_18 */
+   "LED0", /* GPIO_19 */
+   "LED1", /* GPIO_20 */
+   "JTAG_TCK", /* GPIO_21 */
+   "JTAG_TMS", /* GPIO_22 */
+   "JTAG_TDI", /* GPIO_23 */
+   "JTAG_TDO", /* GPIO_24 */
+   "[UART1_RxD]", /* GPIO_25, LSEC pin 13 */
+   "NC", /* GPIO_26 */
+   "[UART1_TxD]", /* GPIO_27, LSEC pin 11 */
+   "SD0_D0", /* GPIO_28 */
+   "SD0_D1", /* GPIO_29 */
+   "SD0_D2", /* GPIO_30 */
+   "SD0_D3", /* GPIO_31 */
+   "SD1_D0", /* GPIO_32 */
+   "SD1_D1", /* GPIO_33 */
+   "SD1_D2", /* GPIO_34 */
+   "SD1_D3", /* GPIO_35 */
+   "SD0_CMD", /* GPIO_36 */
+   "SD0_CLK", /* GPIO_37 */
+   "SD1_CMD", /* GPIO_38 */
+   "SD1_CLK", /* GPIO_39 */
+   "SPI0_SCLK", /* GPIO_40, LSEC pin 8 */
+   "SPI0_CS", /* GPIO_41, LSEC pin 12 */
+   "SPI0_DIN", /* GPIO_42, LSEC pin 10 */
+   "SPI0_DOUT", /* GPIO_43, LSEC pin 14 */
+   "I2C5_SDATA", /* GPIO_44, HSEC pin 36 */
+   "I2C5_SCLK", /* GPIO_45, HSEC pin 38 */
+   "UART0_RX", /* GPIO_46, LSEC pin 7 */
+   "UART0_TX", /* GPIO_47, LSEC pin 5 */
+   "UART0_RTSB", /* GPIO_48, LSEC pin 9 */
+   "UART0_CTSB", /* GPIO_49, LSEC pin 3 */
+   "I2C4_SCLK", /* GPIO_50, HSEC pin 32 */
+   "I2C4_SDATA", /* GPIO_51, HSEC pin 34 */
+   "I2C0_SCLK", /* GPIO_52 */
+   "I2C0_SDATA", /* GPIO_53 */
+   "I2C1_SCLK", /* GPIO_54, LSEC pin 15 */
+   "I2C1_SDATA", /* GPIO_55, LSEC pin 17 */
+   "I2C2_SCLK", /* GPIO_56, LSEC pin 19 */
+   "I2C2_SDATA", /* GPIO_57, LSEC pin 21 */
+   "CSI0_DN0", /* GPIO_58, HSEC pin 10 */
+   "CSI0_DP0", /* GPIO_59, HSEC pin 8 */
+   "CSI0_DN1", /* GPIO_60, HSEC pin 16 */
+   "CSI0_DP1", /* GPIO_61, HSEC pin 14 */
+   "CSI0_CN", /* GPIO_62, HSEC pin 4 */
+   "CSI0_CP", /* GPIO_63, HSEC pin 2 */
+   "CSI0_DN2", /* GPIO_64, HSEC pin 22 */
+   "CSI0_DP2", /* GPIO_65, HSEC pin 20 */
+   "CSI0_DN3", /* GPIO_66, HSEC pin 28 */
+   "CSI0_DP3", /* GPIO_67, 

[PATCH v2 2/5] arm64: dts: actions: Add gpio properties to pinctrl node for S900

[Manivannan Sadhasivam]

Add gpio properties to pinctrl node for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s900.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s900.dtsi 
b/arch/arm64/boot/dts/actions/s900.dtsi
index 0156483f0f4d..aa3a49b0d646 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -178,6 +178,9 @@
compatible = "actions,s900-pinctrl";
reg = <0x0 0xe01b 0x0 0x1000>;
clocks = < CLK_GPIO>;
+   gpio-controller;
+   gpio-ranges = < 0 0 146>;
+   #gpio-cells = <2>;
};
 
timer: timer@e0228000 {
-- 
2.14.1

[PATCH v2 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC

[Manivannan Sadhasivam]

Add gpio support to pinctrl driver for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Andy Shevchenko 
---
 drivers/pinctrl/actions/Kconfig|   1 +
 drivers/pinctrl/actions/pinctrl-owl.c  | 198 +
 drivers/pinctrl/actions/pinctrl-owl.h  |  20 
 drivers/pinctrl/actions/pinctrl-s900.c |  29 -
 4 files changed, 247 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
index ede97cdbbc12..490927b4ea76 100644
--- a/drivers/pinctrl/actions/Kconfig
+++ b/drivers/pinctrl/actions/Kconfig
@@ -4,6 +4,7 @@ config PINCTRL_OWL
select PINMUX
select PINCONF
select GENERIC_PINCONF
+   select GPIOLIB
help
  Say Y here to enable Actions Semi OWL pinctrl driver
 
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c 
b/drivers/pinctrl/actions/pinctrl-owl.c
index ee090697b1e9..76243caa08c6 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,7 @@
  * struct owl_pinctrl - pinctrl state of the device
  * @dev: device handle
  * @pctrldev: pinctrl handle
+ * @chip: gpio chip
  * @lock: spinlock to protect registers
  * @soc: reference to soc_data
  * @base: pinctrl register base address
@@ -38,6 +40,7 @@
 struct owl_pinctrl {
struct device *dev;
struct pinctrl_dev *pctrldev;
+   struct gpio_chip chip;
raw_spinlock_t lock;
struct clk *clk;
const struct owl_pinctrl_soc_data *soc;
@@ -536,6 +539,190 @@ static struct pinctrl_desc owl_pinctrl_desc = {
.owner = THIS_MODULE,
 };
 
+static const struct owl_gpio_port *
+owl_gpio_get_port(struct owl_pinctrl *pctrl, unsigned int *pin)
+{
+   unsigned int start = 0, i;
+
+   for (i = 0; i < pctrl->soc->nports; i++) {
+   const struct owl_gpio_port *port = >soc->ports[i];
+
+   if (*pin >= start && *pin < start + port->pins) {
+   *pin -= start;
+   return port;
+   }
+
+   start += port->pins;
+   }
+
+   return NULL;
+}
+
+static void owl_gpio_update_reg(void __iomem *base, unsigned int pin, int flag)
+{
+   u32 val;
+
+   val = readl_relaxed(base);
+
+   if (flag)
+   val |= BIT(pin);
+   else
+   val &= ~BIT(pin);
+
+   writel_relaxed(val, base);
+}
+
+static int owl_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return -ENODEV;
+
+   gpio_base = pctrl->base + port->offset;
+
+   /*
+* GPIOs have higher priority over other modules, so either setting
+* them as OUT or IN is sufficient
+*/
+   raw_spin_lock_irqsave(>lock, flags);
+   owl_gpio_update_reg(gpio_base + port->outen, offset, true);
+   raw_spin_unlock_irqrestore(>lock, flags);
+
+   return 0;
+}
+
+static void owl_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return;
+
+   gpio_base = pctrl->base + port->offset;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   /* disable gpio output */
+   owl_gpio_update_reg(gpio_base + port->outen, offset, false);
+
+   /* disable gpio input */
+   owl_gpio_update_reg(gpio_base + port->inen, offset, false);
+   raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static int owl_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+   u32 val;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return -ENODEV;
+
+   gpio_base = pctrl->base + port->offset;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   val = readl_relaxed(gpio_base + port->dat);
+   raw_spin_unlock_irqrestore(>lock, flags);
+
+   return !!(val & BIT(offset));
+}
+
+static void owl_gpio_set(struct gpio_chip *chip, unsigned int offset, int 
value)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return;
+
+   

[PATCH v2 1/5] dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC

[Manivannan Sadhasivam]

Add gpio bindings for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
---
 .../devicetree/bindings/pinctrl/actions,s900-pinctrl.txt | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
index fb87c7d74f2e..8fb5a53775e8 100644
--- a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
@@ -8,6 +8,17 @@ Required Properties:
 - reg:  Should contain the register base address and size of
 the pin controller.
 - clocks:   phandle of the clock feeding the pin controller
+- gpio-controller: Marks the device node as a GPIO controller.
+- gpio-ranges: Specifies the mapping between gpio controller and
+   pin-controller pins.
+- #gpio-cells: Should be two. The first cell is the gpio pin number
+   and the second cell is used for optional parameters.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell
+defines the interrupt number, the second encodes
+the trigger flags described in
+bindings/interrupt-controller/interrupts.txt
 
 Please refer to pinctrl-bindings.txt in this directory for details of the
 common pinctrl bindings used by client devices, including the meaning of the
@@ -164,6 +175,11 @@ Example:
   compatible = "actions,s900-pinctrl";
   reg = <0x0 0xe01b 0x0 0x1000>;
   clocks = < CLK_GPIO>;
+  gpio-controller;
+  gpio-ranges = < 0 0 146>;
+  #gpio-cells = <2>;
+  interrupt-controller;
+  #interrupt-cells = <2>;
 
   uart2-default: uart2-default {
   pinmux {
-- 
2.14.1

[PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

[Manivannan Sadhasivam]

Add S900 pinctrl entries under ARCH_ACTIONS

Signed-off-by: Manivannan Sadhasivam 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 640dabc4c311..9e1a17c9b4a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1125,10 +1125,12 @@ F:  arch/arm/mach-actions/
 F: arch/arm/boot/dts/owl-*
 F: arch/arm64/boot/dts/actions/
 F: drivers/clocksource/owl-*
+F: drivers/pinctrl/actions/*
 F: drivers/soc/actions/
 F: include/dt-bindings/power/owl-*
 F: include/linux/soc/actions/
 F: Documentation/devicetree/bindings/arm/actions.txt
+F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
 F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
 F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
 
-- 
2.14.1

[PATCH v2 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC

[Manivannan Sadhasivam]

Add gpio support to pinctrl driver for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Andy Shevchenko 
---
 drivers/pinctrl/actions/Kconfig|   1 +
 drivers/pinctrl/actions/pinctrl-owl.c  | 198 +
 drivers/pinctrl/actions/pinctrl-owl.h  |  20 
 drivers/pinctrl/actions/pinctrl-s900.c |  29 -
 4 files changed, 247 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
index ede97cdbbc12..490927b4ea76 100644
--- a/drivers/pinctrl/actions/Kconfig
+++ b/drivers/pinctrl/actions/Kconfig
@@ -4,6 +4,7 @@ config PINCTRL_OWL
select PINMUX
select PINCONF
select GENERIC_PINCONF
+   select GPIOLIB
help
  Say Y here to enable Actions Semi OWL pinctrl driver
 
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c 
b/drivers/pinctrl/actions/pinctrl-owl.c
index ee090697b1e9..76243caa08c6 100644
--- a/drivers/pinctrl/actions/pinctrl-owl.c
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,7 @@
  * struct owl_pinctrl - pinctrl state of the device
  * @dev: device handle
  * @pctrldev: pinctrl handle
+ * @chip: gpio chip
  * @lock: spinlock to protect registers
  * @soc: reference to soc_data
  * @base: pinctrl register base address
@@ -38,6 +40,7 @@
 struct owl_pinctrl {
struct device *dev;
struct pinctrl_dev *pctrldev;
+   struct gpio_chip chip;
raw_spinlock_t lock;
struct clk *clk;
const struct owl_pinctrl_soc_data *soc;
@@ -536,6 +539,190 @@ static struct pinctrl_desc owl_pinctrl_desc = {
.owner = THIS_MODULE,
 };
 
+static const struct owl_gpio_port *
+owl_gpio_get_port(struct owl_pinctrl *pctrl, unsigned int *pin)
+{
+   unsigned int start = 0, i;
+
+   for (i = 0; i < pctrl->soc->nports; i++) {
+   const struct owl_gpio_port *port = >soc->ports[i];
+
+   if (*pin >= start && *pin < start + port->pins) {
+   *pin -= start;
+   return port;
+   }
+
+   start += port->pins;
+   }
+
+   return NULL;
+}
+
+static void owl_gpio_update_reg(void __iomem *base, unsigned int pin, int flag)
+{
+   u32 val;
+
+   val = readl_relaxed(base);
+
+   if (flag)
+   val |= BIT(pin);
+   else
+   val &= ~BIT(pin);
+
+   writel_relaxed(val, base);
+}
+
+static int owl_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return -ENODEV;
+
+   gpio_base = pctrl->base + port->offset;
+
+   /*
+* GPIOs have higher priority over other modules, so either setting
+* them as OUT or IN is sufficient
+*/
+   raw_spin_lock_irqsave(>lock, flags);
+   owl_gpio_update_reg(gpio_base + port->outen, offset, true);
+   raw_spin_unlock_irqrestore(>lock, flags);
+
+   return 0;
+}
+
+static void owl_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return;
+
+   gpio_base = pctrl->base + port->offset;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   /* disable gpio output */
+   owl_gpio_update_reg(gpio_base + port->outen, offset, false);
+
+   /* disable gpio input */
+   owl_gpio_update_reg(gpio_base + port->inen, offset, false);
+   raw_spin_unlock_irqrestore(>lock, flags);
+}
+
+static int owl_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+   u32 val;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return -ENODEV;
+
+   gpio_base = pctrl->base + port->offset;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   val = readl_relaxed(gpio_base + port->dat);
+   raw_spin_unlock_irqrestore(>lock, flags);
+
+   return !!(val & BIT(offset));
+}
+
+static void owl_gpio_set(struct gpio_chip *chip, unsigned int offset, int 
value)
+{
+   struct owl_pinctrl *pctrl = gpiochip_get_data(chip);
+   const struct owl_gpio_port *port;
+   void __iomem *gpio_base;
+   unsigned long flags;
+
+   port = owl_gpio_get_port(pctrl, );
+   if (WARN_ON(port == NULL))
+   return;
+
+   gpio_base = pctrl->base + port->offset;
+
+   

[PATCH v2 1/5] dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC

[Manivannan Sadhasivam]

Add gpio bindings for Actions Semi S900 SoC.

Signed-off-by: Manivannan Sadhasivam 
---
 .../devicetree/bindings/pinctrl/actions,s900-pinctrl.txt | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
index fb87c7d74f2e..8fb5a53775e8 100644
--- a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
@@ -8,6 +8,17 @@ Required Properties:
 - reg:  Should contain the register base address and size of
 the pin controller.
 - clocks:   phandle of the clock feeding the pin controller
+- gpio-controller: Marks the device node as a GPIO controller.
+- gpio-ranges: Specifies the mapping between gpio controller and
+   pin-controller pins.
+- #gpio-cells: Should be two. The first cell is the gpio pin number
+   and the second cell is used for optional parameters.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell
+defines the interrupt number, the second encodes
+the trigger flags described in
+bindings/interrupt-controller/interrupts.txt
 
 Please refer to pinctrl-bindings.txt in this directory for details of the
 common pinctrl bindings used by client devices, including the meaning of the
@@ -164,6 +175,11 @@ Example:
   compatible = "actions,s900-pinctrl";
   reg = <0x0 0xe01b 0x0 0x1000>;
   clocks = < CLK_GPIO>;
+  gpio-controller;
+  gpio-ranges = < 0 0 146>;
+  #gpio-cells = <2>;
+  interrupt-controller;
+  #interrupt-cells = <2>;
 
   uart2-default: uart2-default {
   pinmux {
-- 
2.14.1

[PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries

[Manivannan Sadhasivam]

Add S900 pinctrl entries under ARCH_ACTIONS

Signed-off-by: Manivannan Sadhasivam 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 640dabc4c311..9e1a17c9b4a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1125,10 +1125,12 @@ F:  arch/arm/mach-actions/
 F: arch/arm/boot/dts/owl-*
 F: arch/arm64/boot/dts/actions/
 F: drivers/clocksource/owl-*
+F: drivers/pinctrl/actions/*
 F: drivers/soc/actions/
 F: include/dt-bindings/power/owl-*
 F: include/linux/soc/actions/
 F: Documentation/devicetree/bindings/arm/actions.txt
+F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
 F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
 F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
 
-- 
2.14.1

[PATCH v2 0/5] Add gpio support for Action Semi S900 SoC

[Manivannan Sadhasivam]

This patchset adds gpio support for Actions Semi S900 SoC by extending
the pinctrl driver. There were previous patches submitted for adding a
standalone gpio driver based on gpiolib. But later on it has been realised
that the gpio functionality is closely tied with pinctrl subsystem for this
OWL family processors. So, having a separate gpio driver will make it hard
to add further functionalities in future. Hence, we decided to drop the
previous patches below adding a standalone gpio support:

dt-bindings: gpio: Add gpio nodes for Actions S900 SoC
arm64: dts: actions: Add S900 gpio nodes
arm64: dts: actions: Add gpio line names to Bubblegum-96 board
gpio: Add gpio driver for Actions OWL S900 SoC
MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries

This patchset consits of incremental patches which will apply with the
previous pinctrl series: Add Actions Semi S900 pinctrl and gpio support,
excluding the dropped patches mentioned above.

Thanks,
Mani

Changes in v2:

* Removed gpiochip_add_pin_range() function and added gpio-ranges property
  in DT.
* Added Reviewed-by tag from Andy.

Manivannan Sadhasivam (5):
  dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC
  arm64: dts: actions: Add gpio properties to pinctrl node for S900
  arm64: dts: actions: Add gpio line names to Bubblegum-96 board
  pinctrl: actions: Add gpio support for Actions S900 SoC
  MAINTAINERS: Add Actions Semi S900 pinctrl entries

 .../bindings/pinctrl/actions,s900-pinctrl.txt  |  16 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/actions/s900-bubblegum-96.dts  | 175 ++
 arch/arm64/boot/dts/actions/s900.dtsi  |   3 +
 drivers/pinctrl/actions/Kconfig|   1 +
 drivers/pinctrl/actions/pinctrl-owl.c  | 198 +
 drivers/pinctrl/actions/pinctrl-owl.h  |  20 +++
 drivers/pinctrl/actions/pinctrl-s900.c |  29 ++-
 8 files changed, 443 insertions(+), 1 deletion(-)

-- 
2.14.1

[PATCH v2 0/5] Add gpio support for Action Semi S900 SoC

[Manivannan Sadhasivam]

This patchset adds gpio support for Actions Semi S900 SoC by extending
the pinctrl driver. There were previous patches submitted for adding a
standalone gpio driver based on gpiolib. But later on it has been realised
that the gpio functionality is closely tied with pinctrl subsystem for this
OWL family processors. So, having a separate gpio driver will make it hard
to add further functionalities in future. Hence, we decided to drop the
previous patches below adding a standalone gpio support:

dt-bindings: gpio: Add gpio nodes for Actions S900 SoC
arm64: dts: actions: Add S900 gpio nodes
arm64: dts: actions: Add gpio line names to Bubblegum-96 board
gpio: Add gpio driver for Actions OWL S900 SoC
MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries

This patchset consits of incremental patches which will apply with the
previous pinctrl series: Add Actions Semi S900 pinctrl and gpio support,
excluding the dropped patches mentioned above.

Thanks,
Mani

Changes in v2:

* Removed gpiochip_add_pin_range() function and added gpio-ranges property
  in DT.
* Added Reviewed-by tag from Andy.

Manivannan Sadhasivam (5):
  dt-bindings: pinctrl: Add gpio bindings for Actions S900 SoC
  arm64: dts: actions: Add gpio properties to pinctrl node for S900
  arm64: dts: actions: Add gpio line names to Bubblegum-96 board
  pinctrl: actions: Add gpio support for Actions S900 SoC
  MAINTAINERS: Add Actions Semi S900 pinctrl entries

 .../bindings/pinctrl/actions,s900-pinctrl.txt  |  16 ++
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/actions/s900-bubblegum-96.dts  | 175 ++
 arch/arm64/boot/dts/actions/s900.dtsi  |   3 +
 drivers/pinctrl/actions/Kconfig|   1 +
 drivers/pinctrl/actions/pinctrl-owl.c  | 198 +
 drivers/pinctrl/actions/pinctrl-owl.h  |  20 +++
 drivers/pinctrl/actions/pinctrl-s900.c |  29 ++-
 8 files changed, 443 insertions(+), 1 deletion(-)

-- 
2.14.1

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:47 AM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
 Hello,

 I've added incremental search for jumping directly to a symbol now.
 Regular expressions are supported as well.

 Some screenshots below:

 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png

 The last screenshot shows how things might look after you jump to a
 symbol. The jumped-to symbol wasn't visible in this case, so show-all
 mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>> _DEBUGFS).  Using:
>>
>> /.*_DEBUG$
>>
>> shows me 6 symbols:
>> ATH9K_COMMON_DEBUG
>> DVB_B2C2_FLEXCOP_DEBUG
>> HAVE_DMA_API_DEBUG
>> IP_DCCP_TFRC_DEBUG
>> NFS_DEBUG
>> PM_SLEEP_DEBUG
>>
>> so where are the other (approx.) 176?
>> see:
>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
>> 182 3649179
>>
>>
>> Anyway, something for you to look at. :)
>>
>> --
>> ~Randy
>
> It's related to how the search is done. Searching for "DEBUG\b" (word
> boundary) instead will find all of them.
>
> A string is generated for each symbol. For symbols with prompts, this
> string includes the prompt as well, so you get e.g.
>
> AB8500_DEBUG "Enable debug info via debugfs"
>
> Those strings are then searched/displayed.
>
> What you got with your search was all symbols whose names end in
> "_DEBUG" that don't have a prompt.
>
> The nice thing about searching both the name and the prompt is that
> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
> add menus to the search, by generating 'menu: "menu title"' strings
> for them.
>
> It's a bit awkward/unintuitive that what you tried doesn't work
> though. Maybe the symbol name could be searched separately from the
> prompt, though I'd be a bit sad to abandon the super simple
> single-string-per-entry implementation approach. :)
>
> Thanks,
> Ulf

Need to make that "_DEBUG\b" to avoid getting a bunch of hits in prompts though.

Searching the name separately from the prompt might give nicer
behavior when regexes are involved. People might not expect e.g.
'debug.*info' to match for AB8500_DEBUG either, but it would, because
the prompt has "info" in it. OTOH, for searches like that, you'd
usually just type "debug info", and then narrow it down with more
words.

Any opinions?

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:47 AM, Ulf Magnusson  wrote:
> On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
>> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
 Hello,

 I've added incremental search for jumping directly to a symbol now.
 Regular expressions are supported as well.

 Some screenshots below:

 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
 https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png

 The last screenshot shows how things might look after you jump to a
 symbol. The jumped-to symbol wasn't visible in this case, so show-all
 mode was turned on automatically.
>>>
>>> Hi Ulf,
>>>
>>>
>>>
>>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the 
>>> UI now.
>>>
>>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>>> Kconfiglib/menuconfig.py
>>>
>>> so yes, a real Makefile target would be nice. :)
>>
>> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
>> _DEBUGFS).  Using:
>>
>> /.*_DEBUG$
>>
>> shows me 6 symbols:
>> ATH9K_COMMON_DEBUG
>> DVB_B2C2_FLEXCOP_DEBUG
>> HAVE_DMA_API_DEBUG
>> IP_DCCP_TFRC_DEBUG
>> NFS_DEBUG
>> PM_SLEEP_DEBUG
>>
>> so where are the other (approx.) 176?
>> see:
>> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
>> 182 3649179
>>
>>
>> Anyway, something for you to look at. :)
>>
>> --
>> ~Randy
>
> It's related to how the search is done. Searching for "DEBUG\b" (word
> boundary) instead will find all of them.
>
> A string is generated for each symbol. For symbols with prompts, this
> string includes the prompt as well, so you get e.g.
>
> AB8500_DEBUG "Enable debug info via debugfs"
>
> Those strings are then searched/displayed.
>
> What you got with your search was all symbols whose names end in
> "_DEBUG" that don't have a prompt.
>
> The nice thing about searching both the name and the prompt is that
> e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
> add menus to the search, by generating 'menu: "menu title"' strings
> for them.
>
> It's a bit awkward/unintuitive that what you tried doesn't work
> though. Maybe the symbol name could be searched separately from the
> prompt, though I'd be a bit sad to abandon the super simple
> single-string-per-entry implementation approach. :)
>
> Thanks,
> Ulf

Need to make that "_DEBUG\b" to avoid getting a bunch of hits in prompts though.

Searching the name separately from the prompt might give nicer
behavior when regexes are involved. People might not expect e.g.
'debug.*info' to match for AB8500_DEBUG either, but it would, because
the prompt has "info" in it. OTOH, for searches like that, you'd
usually just type "debug info", and then narrow it down with more
words.

Any opinions?

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
> _DEBUGFS).  Using:
>
> /.*_DEBUG$
>
> shows me 6 symbols:
> ATH9K_COMMON_DEBUG
> DVB_B2C2_FLEXCOP_DEBUG
> HAVE_DMA_API_DEBUG
> IP_DCCP_TFRC_DEBUG
> NFS_DEBUG
> PM_SLEEP_DEBUG
>
> so where are the other (approx.) 176?
> see:
> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
> 182 3649179
>
>
> Anyway, something for you to look at. :)
>
> --
> ~Randy

It's related to how the search is done. Searching for "DEBUG\b" (word
boundary) instead will find all of them.

A string is generated for each symbol. For symbols with prompts, this
string includes the prompt as well, so you get e.g.

AB8500_DEBUG "Enable debug info via debugfs"

Those strings are then searched/displayed.

What you got with your search was all symbols whose names end in
"_DEBUG" that don't have a prompt.

The nice thing about searching both the name and the prompt is that
e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
add menus to the search, by generating 'menu: "menu title"' strings
for them.

It's a bit awkward/unintuitive that what you tried doesn't work
though. Maybe the symbol name could be searched separately from the
prompt, though I'd be a bit sad to abandon the super simple
single-string-per-entry implementation approach. :)

Thanks,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 6:03 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
> I want to see all kconfig symbols that end with "_DEBUG" (so excluding
> _DEBUGFS).  Using:
>
> /.*_DEBUG$
>
> shows me 6 symbols:
> ATH9K_COMMON_DEBUG
> DVB_B2C2_FLEXCOP_DEBUG
> HAVE_DMA_API_DEBUG
> IP_DCCP_TFRC_DEBUG
> NFS_DEBUG
> PM_SLEEP_DEBUG
>
> so where are the other (approx.) 176?
> see:
> $ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
> 182 3649179
>
>
> Anyway, something for you to look at. :)
>
> --
> ~Randy

It's related to how the search is done. Searching for "DEBUG\b" (word
boundary) instead will find all of them.

A string is generated for each symbol. For symbols with prompts, this
string includes the prompt as well, so you get e.g.

AB8500_DEBUG "Enable debug info via debugfs"

Those strings are then searched/displayed.

What you got with your search was all symbols whose names end in
"_DEBUG" that don't have a prompt.

The nice thing about searching both the name and the prompt is that
e.g. "debugfs ab8500" will find the symbol above. I'm also planning to
add menus to the search, by generating 'menu: "menu title"' strings
for them.

It's a bit awkward/unintuitive that what you tried doesn't work
though. Maybe the symbol name could be searched separately from the
prompt, though I'd be a bit sad to abandon the super simple
single-string-per-entry implementation approach. :)

Thanks,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
>
> Enter: / (search)
> then:  * (Bang) [this was just an unlucky typo on my part]
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
> for regex in s.split()]
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
> for regex in s.split()]
>   File "/usr/lib64/python3.4/re.py", line 223, in compile
> return _compile(pattern, flags)
>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
> p = sre_compile.compile(pattern, flags)
>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
> p = sre_parse.parse(p, flags)
>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
> p = _parse_sub(source, pattern, 0)
>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
> itemsappend(_parse(source, state))
>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
> raise error("nothing to repeat")
> sre_constants.error: nothing to repeat
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
> print(curses.wrapper(_menuconfig))
>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
> _jump_to_dialog()
>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
> bad_re = e.msg
> AttributeError: 'error' object has no attribute 'msg'
>
>
>
> --
> ~Randy

Thanks for the report!

Invalid regular expressions are detected, but it looks like the 'msg'
field of re.error was added in Python 3.5 (you have 3.4).

I'll check if the 'msg' field exists and fall back to just printing
"Invalid regular expression" otherwise. The 'msg' field just gives a
more informative error
("Bad regular expression: nothing to repeat" in this case).

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Ulf Magnusson]

On Sun, May 20, 2018 at 5:51 AM, Randy Dunlap  wrote:
> On 05/19/2018 08:45 PM, Randy Dunlap wrote:
>> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>>> Hello,
>>>
>>> I've added incremental search for jumping directly to a symbol now.
>>> Regular expressions are supported as well.
>>>
>>> Some screenshots below:
>>>
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>>
>>> The last screenshot shows how things might look after you jump to a
>>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>>> mode was turned on automatically.
>>
>> Hi Ulf,
>>
>>
>> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
>> now.
>>
>> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
>> Kconfiglib/menuconfig.py
>>
>> so yes, a real Makefile target would be nice. :)
>
>
> Enter: / (search)
> then:  * (Bang) [this was just an unlucky typo on my part]
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
> for regex in s.split()]
>   File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
> for regex in s.split()]
>   File "/usr/lib64/python3.4/re.py", line 223, in compile
> return _compile(pattern, flags)
>   File "/usr/lib64/python3.4/re.py", line 294, in _compile
> p = sre_compile.compile(pattern, flags)
>   File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
> p = sre_parse.parse(p, flags)
>   File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
> p = _parse_sub(source, pattern, 0)
>   File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
> itemsappend(_parse(source, state))
>   File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
> raise error("nothing to repeat")
> sre_constants.error: nothing to repeat
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
> menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
>   File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
> print(curses.wrapper(_menuconfig))
>   File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
> _jump_to_dialog()
>   File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
> bad_re = e.msg
> AttributeError: 'error' object has no attribute 'msg'
>
>
>
> --
> ~Randy

Thanks for the report!

Invalid regular expressions are detected, but it looks like the 'msg'
field of re.error was added in Python 3.5 (you have 3.4).

I'll check if the 'msg' field exists and fall back to just printing
"Invalid regular expression" otherwise. The 'msg' field just gives a
more informative error
("Bad regular expression: nothing to repeat" in this case).

Cheers,
Ulf

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Randy Dunlap]

On 05/19/2018 08:45 PM, Randy Dunlap wrote:
> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>> Hello,
>>
>> I've added incremental search for jumping directly to a symbol now.
>> Regular expressions are supported as well.
>>
>> Some screenshots below:
>>
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>
>> The last screenshot shows how things might look after you jump to a
>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>> mode was turned on automatically.
> 
> Hi Ulf,
> 
> 
> 
> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
> now.
> 
> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
> Kconfiglib/menuconfig.py
> 
> so yes, a real Makefile target would be nice. :)

I want to see all kconfig symbols that end with "_DEBUG" (so excluding
_DEBUGFS).  Using:

/.*_DEBUG$

shows me 6 symbols:
ATH9K_COMMON_DEBUG
DVB_B2C2_FLEXCOP_DEBUG
HAVE_DMA_API_DEBUG
IP_DCCP_TFRC_DEBUG
NFS_DEBUG
PM_SLEEP_DEBUG

so where are the other (approx.) 176?
see:
$ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
182 3649179


Anyway, something for you to look at. :)

-- 
~Randy

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Randy Dunlap]

On 05/19/2018 08:45 PM, Randy Dunlap wrote:
> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>> Hello,
>>
>> I've added incremental search for jumping directly to a symbol now.
>> Regular expressions are supported as well.
>>
>> Some screenshots below:
>>
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>
>> The last screenshot shows how things might look after you jump to a
>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>> mode was turned on automatically.
> 
> Hi Ulf,
> 
> 
> 
> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
> now.
> 
> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
> Kconfiglib/menuconfig.py
> 
> so yes, a real Makefile target would be nice. :)

I want to see all kconfig symbols that end with "_DEBUG" (so excluding
_DEBUGFS).  Using:

/.*_DEBUG$

shows me 6 symbols:
ATH9K_COMMON_DEBUG
DVB_B2C2_FLEXCOP_DEBUG
HAVE_DMA_API_DEBUG
IP_DCCP_TFRC_DEBUG
NFS_DEBUG
PM_SLEEP_DEBUG

so where are the other (approx.) 176?
see:
$ find . -name Kconfig\* | xargs grep "config.*_DEBUG$" | grep -v \.orig | wc
182 3649179


Anyway, something for you to look at. :)

-- 
~Randy

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Randy Dunlap]

On 05/19/2018 08:45 PM, Randy Dunlap wrote:
> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>> Hello,
>>
>> I've added incremental search for jumping directly to a symbol now.
>> Regular expressions are supported as well.
>>
>> Some screenshots below:
>>
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>
>> The last screenshot shows how things might look after you jump to a
>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>> mode was turned on automatically.
> 
> Hi Ulf,
> 
> 
> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
> now.
> 
> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
> Kconfiglib/menuconfig.py
> 
> so yes, a real Makefile target would be nice. :)


Enter: / (search)
then:  * (Bang) [this was just an unlucky typo on my part]

Traceback (most recent call last):
  File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
for regex in s.split()]
  File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
for regex in s.split()]
  File "/usr/lib64/python3.4/re.py", line 223, in compile
return _compile(pattern, flags)
  File "/usr/lib64/python3.4/re.py", line 294, in _compile
p = sre_compile.compile(pattern, flags)
  File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
p = sre_parse.parse(p, flags)
  File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
p = _parse_sub(source, pattern, 0)
  File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
itemsappend(_parse(source, state))
  File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
raise error("nothing to repeat")
sre_constants.error: nothing to repeat

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
  File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
print(curses.wrapper(_menuconfig))
  File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
  File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
_jump_to_dialog()
  File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
bad_re = e.msg
AttributeError: 'error' object has no attribute 'msg'



-- 
~Randy

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Randy Dunlap]

On 05/19/2018 08:45 PM, Randy Dunlap wrote:
> On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
>> Hello,
>>
>> I've added incremental search for jumping directly to a symbol now.
>> Regular expressions are supported as well.
>>
>> Some screenshots below:
>>
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
>> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
>>
>> The last screenshot shows how things might look after you jump to a
>> symbol. The jumped-to symbol wasn't visible in this case, so show-all
>> mode was turned on automatically.
> 
> Hi Ulf,
> 
> 
> Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
> now.
> 
> ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
> Kconfiglib/menuconfig.py
> 
> so yes, a real Makefile target would be nice. :)


Enter: / (search)
then:  * (Bang) [this was just an unlucky typo on my part]

Traceback (most recent call last):
  File "/home/rdunlap/scripts/menuconfig.py", line 1447, in _jump_to_dialog
for regex in s.split()]
  File "/home/rdunlap/scripts/menuconfig.py", line 1447, in 
for regex in s.split()]
  File "/usr/lib64/python3.4/re.py", line 223, in compile
return _compile(pattern, flags)
  File "/usr/lib64/python3.4/re.py", line 294, in _compile
p = sre_compile.compile(pattern, flags)
  File "/usr/lib64/python3.4/sre_compile.py", line 568, in compile
p = sre_parse.parse(p, flags)
  File "/usr/lib64/python3.4/sre_parse.py", line 780, in parse
p = _parse_sub(source, pattern, 0)
  File "/usr/lib64/python3.4/sre_parse.py", line 377, in _parse_sub
itemsappend(_parse(source, state))
  File "/usr/lib64/python3.4/sre_parse.py", line 586, in _parse
raise error("nothing to repeat")
sre_constants.error: nothing to repeat

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/rdunlap/scripts/menuconfig.py", line 2389, in 
menuconfig(Kconfig("Kconfig" if len(sys.argv) < 2 else sys.argv[1]))
  File "/home/rdunlap/scripts/menuconfig.py", line 340, in menuconfig
print(curses.wrapper(_menuconfig))
  File "/usr/lib64/python3.4/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
  File "/home/rdunlap/scripts/menuconfig.py", line 483, in _menuconfig
_jump_to_dialog()
  File "/home/rdunlap/scripts/menuconfig.py", line 1466, in _jump_to_dialog
bad_re = e.msg
AttributeError: 'error' object has no attribute 'msg'



-- 
~Randy

[PATCH] mtd: mtdoops: optionally dump boottime

[Stefan M Schaeckeler]

Optionally dump boottime on the mtd device in the form of

<0>[   0.00] Boot time mm/dd/ hh:mm:ss

Time-stamps of oops messages are in seconds since boottime. Recording also
the boottime helps correlating oopses with other events having occured at
the same time. This correlation will be otherwise lost after (multiple)
reboots.

Signed-off-by: Stefan M Schaeckeler 
---
 drivers/mtd/mtdoops.c | 38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
index 9f25111..11f93aa 100644
--- a/drivers/mtd/mtdoops.c
+++ b/drivers/mtd/mtdoops.c
@@ -54,6 +54,11 @@ module_param(dump_oops, int, 0600);
 MODULE_PARM_DESC(dump_oops,
"set to 1 to dump oopses, 0 to only dump panics (default 1)");
 
+static bool dump_boottime = false;
+module_param(dump_boottime, bool, 0400);
+MODULE_PARM_DESC(dump_boottime,
+   "set to 1 to dump boottime, 0 to disable (default 0)");
+
 static struct mtdoops_context {
struct kmsg_dumper dump;
 
@@ -69,6 +74,10 @@ static struct mtdoops_context {
void *oops_buf;
 } oops_cxt;
 
+/* fake kernel message syslog level and monotonic timestamp */
+#define boottime_prefix "<0>[   0.00] Boot time "
+static char boottime[100] = {0};
+
 static void mark_page_used(struct mtdoops_context *cxt, int page)
 {
set_bit(page, cxt->oops_page_used);
@@ -285,13 +294,17 @@ static void mtdoops_do_dump(struct kmsg_dumper *dumper,
 {
struct mtdoops_context *cxt = container_of(dumper,
struct mtdoops_context, dump);
+   u8 boot_len = strlen(boottime); /* 0 if dump_boottime is not set */
 
/* Only dump oopses if dump_oops is set */
if (reason == KMSG_DUMP_OOPS && !dump_oops)
return;
 
-   kmsg_dump_get_buffer(dumper, true, cxt->oops_buf + MTDOOPS_HEADER_SIZE,
-record_size - MTDOOPS_HEADER_SIZE, NULL);
+   strncpy(cxt->oops_buf + MTDOOPS_HEADER_SIZE, boottime, boot_len);
+
+   kmsg_dump_get_buffer(dumper, true, cxt->oops_buf + MTDOOPS_HEADER_SIZE +
+boot_len, record_size - (MTDOOPS_HEADER_SIZE +
+boot_len), NULL);
 
/* Panics must be written immediately */
if (reason != KMSG_DUMP_OOPS)
@@ -350,7 +363,13 @@ static void mtdoops_notify_add(struct mtd_info *mtd)
cxt->mtd = mtd;
cxt->oops_pages = (int)mtd->size / record_size;
find_next_position(cxt);
-   printk(KERN_INFO "mtdoops: Attached to MTD device %d\n", mtd->index);
+   if (dump_boottime) {
+   printk(KERN_INFO "mtdoops: Attached to MTD device %d "
+  "dumping boottime\n", mtd->index);
+   } else {
+   printk(KERN_INFO "mtdoops: Attached to MTD device %d "
+  "not dumping boottime\n", mtd->index);
+   }
 }
 
 static void mtdoops_notify_remove(struct mtd_info *mtd)
@@ -379,6 +398,19 @@ static int __init mtdoops_init(void)
struct mtdoops_context *cxt = _cxt;
int mtd_index;
char *endp;
+   struct timespec64 bt;
+   struct tm tm_val;
+
+   if (dump_boottime) {
+   /* Precompute boot time ahead of an oops */
+   getboottime64();
+   time_to_tm(bt.tv_sec, 0, _val);
+
+   snprintf(boottime, sizeof(boottime),
+boottime_prefix "%02d/%02d/%4d %02d:%02d:%02d\n",
+tm_val.tm_mon + 1, tm_val.tm_mday, tm_val.tm_year + 1900,
+tm_val.tm_hour, tm_val.tm_min, tm_val.tm_sec);
+   }
 
if (strlen(mtddev) == 0) {
printk(KERN_ERR "mtdoops: mtd device (mtddev=name/number) must 
be supplied\n");
-- 
2.10.3.dirty

[PATCH] mtd: mtdoops: optionally dump boottime

[Stefan M Schaeckeler]

Optionally dump boottime on the mtd device in the form of

<0>[   0.00] Boot time mm/dd/ hh:mm:ss

Time-stamps of oops messages are in seconds since boottime. Recording also
the boottime helps correlating oopses with other events having occured at
the same time. This correlation will be otherwise lost after (multiple)
reboots.

Signed-off-by: Stefan M Schaeckeler 
---
 drivers/mtd/mtdoops.c | 38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
index 9f25111..11f93aa 100644
--- a/drivers/mtd/mtdoops.c
+++ b/drivers/mtd/mtdoops.c
@@ -54,6 +54,11 @@ module_param(dump_oops, int, 0600);
 MODULE_PARM_DESC(dump_oops,
"set to 1 to dump oopses, 0 to only dump panics (default 1)");
 
+static bool dump_boottime = false;
+module_param(dump_boottime, bool, 0400);
+MODULE_PARM_DESC(dump_boottime,
+   "set to 1 to dump boottime, 0 to disable (default 0)");
+
 static struct mtdoops_context {
struct kmsg_dumper dump;
 
@@ -69,6 +74,10 @@ static struct mtdoops_context {
void *oops_buf;
 } oops_cxt;
 
+/* fake kernel message syslog level and monotonic timestamp */
+#define boottime_prefix "<0>[   0.00] Boot time "
+static char boottime[100] = {0};
+
 static void mark_page_used(struct mtdoops_context *cxt, int page)
 {
set_bit(page, cxt->oops_page_used);
@@ -285,13 +294,17 @@ static void mtdoops_do_dump(struct kmsg_dumper *dumper,
 {
struct mtdoops_context *cxt = container_of(dumper,
struct mtdoops_context, dump);
+   u8 boot_len = strlen(boottime); /* 0 if dump_boottime is not set */
 
/* Only dump oopses if dump_oops is set */
if (reason == KMSG_DUMP_OOPS && !dump_oops)
return;
 
-   kmsg_dump_get_buffer(dumper, true, cxt->oops_buf + MTDOOPS_HEADER_SIZE,
-record_size - MTDOOPS_HEADER_SIZE, NULL);
+   strncpy(cxt->oops_buf + MTDOOPS_HEADER_SIZE, boottime, boot_len);
+
+   kmsg_dump_get_buffer(dumper, true, cxt->oops_buf + MTDOOPS_HEADER_SIZE +
+boot_len, record_size - (MTDOOPS_HEADER_SIZE +
+boot_len), NULL);
 
/* Panics must be written immediately */
if (reason != KMSG_DUMP_OOPS)
@@ -350,7 +363,13 @@ static void mtdoops_notify_add(struct mtd_info *mtd)
cxt->mtd = mtd;
cxt->oops_pages = (int)mtd->size / record_size;
find_next_position(cxt);
-   printk(KERN_INFO "mtdoops: Attached to MTD device %d\n", mtd->index);
+   if (dump_boottime) {
+   printk(KERN_INFO "mtdoops: Attached to MTD device %d "
+  "dumping boottime\n", mtd->index);
+   } else {
+   printk(KERN_INFO "mtdoops: Attached to MTD device %d "
+  "not dumping boottime\n", mtd->index);
+   }
 }
 
 static void mtdoops_notify_remove(struct mtd_info *mtd)
@@ -379,6 +398,19 @@ static int __init mtdoops_init(void)
struct mtdoops_context *cxt = _cxt;
int mtd_index;
char *endp;
+   struct timespec64 bt;
+   struct tm tm_val;
+
+   if (dump_boottime) {
+   /* Precompute boot time ahead of an oops */
+   getboottime64();
+   time_to_tm(bt.tv_sec, 0, _val);
+
+   snprintf(boottime, sizeof(boottime),
+boottime_prefix "%02d/%02d/%4d %02d:%02d:%02d\n",
+tm_val.tm_mon + 1, tm_val.tm_mday, tm_val.tm_year + 1900,
+tm_val.tm_hour, tm_val.tm_min, tm_val.tm_sec);
+   }
 
if (strlen(mtddev) == 0) {
printk(KERN_ERR "mtdoops: mtd device (mtddev=name/number) must 
be supplied\n");
-- 
2.10.3.dirty

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Randy Dunlap]

On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
> Hello,
> 
> I've added incremental search for jumping directly to a symbol now.
> Regular expressions are supported as well.
> 
> Some screenshots below:
> 
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
> 
> The last screenshot shows how things might look after you jump to a
> symbol. The jumped-to symbol wasn't visible in this case, so show-all
> mode was turned on automatically.

Hi Ulf,

Do I need to save kconfiglib.py in a special location?

With (new) kconfiglib.py and menuconfig.py, I am getting this:

$ make ARCH=x86_64 O=xx64 iscriptconfig
make[1]: Entering directory '/home/rdunlap/lnx/lnx-417-rc3/xx64'
  GEN ./Makefile
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'kconfiglib'
>>> 

and then if I (being a Python novice) copy kconfiglib.py to
/usr/lib/python3.4/site-packages/ and try again, I get 16 warning messages 
(below)
and then this:

A Kconfig instance 'kconf' for the architecture x86_64 has been created.
>>> 

What am I supposed to do now?

Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
now.

ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
Kconfiglib/menuconfig.py

so yes, a real Makefile target would be nice. :)


thanks,
-- 
~Randy

the 16 warning messages:

warning: SCSI_DPT_I2O (defined at drivers/scsi/Kconfig:482) has leading or 
trailing whitespace in its prompt
warning: ATM_FIRESTREAM (defined at drivers/atm/Kconfig:149) has leading or 
trailing whitespace in its prompt
warning: IWLWIFI (defined at drivers/net/wireless/intel/iwlwifi/Kconfig:1) has 
leading or trailing whitespace in its prompt
warning: REGULATOR_MAX8973 (defined at drivers/regulator/Kconfig:479) has 
leading or trailing whitespace in its prompt
warning: MEMSTICK_TIFM_MS (defined at drivers/memstick/host/Kconfig:7) has 
leading or trailing whitespace in its prompt
warning: MV_XOR_V2 (defined at drivers/dma/Kconfig:374) has leading or trailing 
whitespace in its prompt
warning: PANEL_LCD_PIN_E (defined at drivers/auxdisplay/Kconfig:335) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_RS (defined at drivers/auxdisplay/Kconfig:350) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_RW (defined at drivers/auxdisplay/Kconfig:365) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_SCL (defined at drivers/auxdisplay/Kconfig:380) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_SDA (defined at drivers/auxdisplay/Kconfig:395) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_BL (defined at drivers/auxdisplay/Kconfig:410) has 
leading or trailing whitespace in its prompt
warning: INTEGRITY_AUDIT (defined at security/integrity/Kconfig:54) has leading 
or trailing whitespace in its prompt
warning: the choice symbol VIRT_CPU_ACCOUNTING_GEN (defined at 
init/Kconfig:359) is selected by the following symbols, which has no effect: 
 - NO_HZ_FULL (defined at kernel/time/Kconfig:85)
warning: the choice symbol M486 (defined at arch/x86/Kconfig.cpu:53) is 
selected by the following symbols, which has no effect: 
 - X86_RDC321X (defined at arch/x86/Kconfig:653)
warning: the choice symbol FB_LITTLE_ENDIAN (defined at 
drivers/video/fbdev/Kconfig:168) is selected by the following symbols, which 
has no effect: 
 - FB_MB862XX_LIME (defined at drivers/video/fbdev/Kconfig:2190)

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

[Randy Dunlap]

On 05/08/2018 09:59 AM, Ulf Magnusson wrote:
> Hello,
> 
> I've added incremental search for jumping directly to a symbol now.
> Regular expressions are supported as well.
> 
> Some screenshots below:
> 
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss10.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss11.png
> https://raw.githubusercontent.com/ulfalizer/Kconfiglib/screenshots/screenshots/ss13.png
> 
> The last screenshot shows how things might look after you jump to a
> symbol. The jumped-to symbol wasn't visible in this case, so show-all
> mode was turned on automatically.

Hi Ulf,

Do I need to save kconfiglib.py in a special location?

With (new) kconfiglib.py and menuconfig.py, I am getting this:

$ make ARCH=x86_64 O=xx64 iscriptconfig
make[1]: Entering directory '/home/rdunlap/lnx/lnx-417-rc3/xx64'
  GEN ./Makefile
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'kconfiglib'
>>> 

and then if I (being a Python novice) copy kconfiglib.py to
/usr/lib/python3.4/site-packages/ and try again, I get 16 warning messages 
(below)
and then this:

A Kconfig instance 'kconf' for the architecture x86_64 has been created.
>>> 

What am I supposed to do now?

Hm, OK, I used the trick that you supplied a few weeks ago and I have the UI 
now.

ARCH=x86 SRCARCH=x86 KERNELVERSION=`make kernelversion` \
Kconfiglib/menuconfig.py

so yes, a real Makefile target would be nice. :)


thanks,
-- 
~Randy

the 16 warning messages:

warning: SCSI_DPT_I2O (defined at drivers/scsi/Kconfig:482) has leading or 
trailing whitespace in its prompt
warning: ATM_FIRESTREAM (defined at drivers/atm/Kconfig:149) has leading or 
trailing whitespace in its prompt
warning: IWLWIFI (defined at drivers/net/wireless/intel/iwlwifi/Kconfig:1) has 
leading or trailing whitespace in its prompt
warning: REGULATOR_MAX8973 (defined at drivers/regulator/Kconfig:479) has 
leading or trailing whitespace in its prompt
warning: MEMSTICK_TIFM_MS (defined at drivers/memstick/host/Kconfig:7) has 
leading or trailing whitespace in its prompt
warning: MV_XOR_V2 (defined at drivers/dma/Kconfig:374) has leading or trailing 
whitespace in its prompt
warning: PANEL_LCD_PIN_E (defined at drivers/auxdisplay/Kconfig:335) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_RS (defined at drivers/auxdisplay/Kconfig:350) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_RW (defined at drivers/auxdisplay/Kconfig:365) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_SCL (defined at drivers/auxdisplay/Kconfig:380) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_SDA (defined at drivers/auxdisplay/Kconfig:395) has 
leading or trailing whitespace in its prompt
warning: PANEL_LCD_PIN_BL (defined at drivers/auxdisplay/Kconfig:410) has 
leading or trailing whitespace in its prompt
warning: INTEGRITY_AUDIT (defined at security/integrity/Kconfig:54) has leading 
or trailing whitespace in its prompt
warning: the choice symbol VIRT_CPU_ACCOUNTING_GEN (defined at 
init/Kconfig:359) is selected by the following symbols, which has no effect: 
 - NO_HZ_FULL (defined at kernel/time/Kconfig:85)
warning: the choice symbol M486 (defined at arch/x86/Kconfig.cpu:53) is 
selected by the following symbols, which has no effect: 
 - X86_RDC321X (defined at arch/x86/Kconfig:653)
warning: the choice symbol FB_LITTLE_ENDIAN (defined at 
drivers/video/fbdev/Kconfig:168) is selected by the following symbols, which 
has no effect: 
 - FB_MB862XX_LIME (defined at drivers/video/fbdev/Kconfig:2190)

[lkp-robot] [workqueue] f303fccb82: kmsg.workqueue:round-robin_CPU_selection_forced,expect_performance_impact

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: f303fccb82928790ec58eea82722bd5c54d300b3 ("workqueue: implement 
"workqueue.debug_force_rr_cpu" debug feature")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


[0.890976] workqueue: round-robin CPU selection forced, expect performance 
impact


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y

[lkp-robot] [workqueue] f303fccb82: kmsg.workqueue:round-robin_CPU_selection_forced,expect_performance_impact

[kernel test robot]

FYI, we noticed the following commit (built with gcc-4.9):

commit: f303fccb82928790ec58eea82722bd5c54d300b3 ("workqueue: implement 
"workqueue.debug_force_rr_cpu" debug feature")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


[0.890976] workqueue: round-robin CPU selection forced, expect performance 
impact


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

[kbuild test robot]

Hi Andrea,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-com20020-Add-com20020-io-mapped-version/20180520-083936
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/net/arcnet/com90xx.c:484:13: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:534:28: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:613:13: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:233:21: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:234:25: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:247:17: sparse: undefined identifier 
'arcnet_writeb'
   drivers/net/arcnet/com90xx.c:248:21: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:391:29: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:405:33: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:428:17: sparse: undefined identifier 
'arcnet_writeb'
   drivers/net/arcnet/com90xx.c:446:21: sparse: undefined identifier 
'arcnet_readb'
>> drivers/net/arcnet/com90xx.c:233:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:234:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:247:30: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:248:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:391:41: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:405:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:428:30: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:446:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:484:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:485:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:486:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:534:40: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:613:25: sparse: call with no type!
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/com90xx.c: In function 'com90xx_probe':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:161:7: note: in expansion of macro 'arcnet_inb'
  if (arcnet_inb(ioaddr, COM9026_REG_R_STATUS) == 0xFF) {
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:171:3: note: in expansion of macro 'arcnet_inb'
  arcnet_inb(ioaddr, COM9026_REG_R_RESET);
  ^~
   drivers/net/arcnet/com90xx.c:233:7: error: implicit declaration of function 
'arcnet_readb'; did you mean 'arcnet_outsb'? 
[-Werror=implicit-function-declaration]
  if (arcnet_readb(base, COM9026_REG_R_STATUS) != TESTvalue) {
  ^~~~
  arcnet_outsb
   drivers/net/arcnet/com90xx.c:247:3: error: implicit declaration of function 
'arcnet_writeb'; did you mean 'arcnet_outsb'? 
[-Werror=implicit-function-declaration]
  arcnet_writeb(0x42, base, COM9026_REG_W_INTMASK);
  ^
  arcnet_outsb
   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:312:12: note: in expansion of macro 'arcnet_inb'
  status = arcnet_inb(ioaddr, COM9026_REG_R_STATUS);
   ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:324:3: note: in expansion of macro 'arcnet_outb'
  arcnet_outb(CFLAGScmd | RESETclear | CONFIGclear,
  ^~~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
   

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

[kbuild test robot]

Hi Andrea,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-com20020-Add-com20020-io-mapped-version/20180520-083936
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/net/arcnet/com90xx.c:484:13: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:534:28: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:613:13: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:233:21: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:234:25: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:247:17: sparse: undefined identifier 
'arcnet_writeb'
   drivers/net/arcnet/com90xx.c:248:21: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:391:29: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:405:33: sparse: undefined identifier 
'arcnet_readb'
   drivers/net/arcnet/com90xx.c:428:17: sparse: undefined identifier 
'arcnet_writeb'
   drivers/net/arcnet/com90xx.c:446:21: sparse: undefined identifier 
'arcnet_readb'
>> drivers/net/arcnet/com90xx.c:233:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:234:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:247:30: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:248:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:391:41: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:405:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:428:30: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:446:33: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:484:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:485:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:486:25: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:534:40: sparse: call with no type!
   drivers/net/arcnet/com90xx.c:613:25: sparse: call with no type!
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
>> drivers/net/arcnet/com90xx.c:615:25: sparse: unknown expression (4 0)
   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/com90xx.c: In function 'com90xx_probe':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:161:7: note: in expansion of macro 'arcnet_inb'
  if (arcnet_inb(ioaddr, COM9026_REG_R_STATUS) == 0xFF) {
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:171:3: note: in expansion of macro 'arcnet_inb'
  arcnet_inb(ioaddr, COM9026_REG_R_RESET);
  ^~
   drivers/net/arcnet/com90xx.c:233:7: error: implicit declaration of function 
'arcnet_readb'; did you mean 'arcnet_outsb'? 
[-Werror=implicit-function-declaration]
  if (arcnet_readb(base, COM9026_REG_R_STATUS) != TESTvalue) {
  ^~~~
  arcnet_outsb
   drivers/net/arcnet/com90xx.c:247:3: error: implicit declaration of function 
'arcnet_writeb'; did you mean 'arcnet_outsb'? 
[-Werror=implicit-function-declaration]
  arcnet_writeb(0x42, base, COM9026_REG_W_INTMASK);
  ^
  arcnet_outsb
   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:312:12: note: in expansion of macro 'arcnet_inb'
  status = arcnet_inb(ioaddr, COM9026_REG_R_STATUS);
   ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:324:3: note: in expansion of macro 'arcnet_outb'
  arcnet_outb(CFLAGScmd | RESETclear | CONFIGclear,
  ^~~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
   

Re: [PATCH net-next] net: dsa: b53: Extend platform data to include DSA ports

[Florian Fainelli]

On May 19, 2018 6:42:50 PM PDT, Andrew Lunn  wrote:
>On Sat, May 19, 2018 at 03:55:10PM -0700, Florian Fainelli wrote:
>> Provide a means for !OF platforms to supply their DSA platform data
>> configuration using the dsa_platform_data structure.
>
>Hi Florian
>
>It seems a bit odd adding the header file, but no code. Yes, this will
>help simplify the merge dependencies for the ZII boards next cycle,
>but can we have the actual code as well?

The existing b53_common.c file already makes use of platform data the only 
thing that was missing was a dsa_chip_data structure correctly placed for the 
core DSA layer to obtain port information. This was present from day one in the 
b53 driver because it is also the mechanism used by the bus specific drivers to 
pass information to the core b53 driver file.
Hi Andrew,
-- 
Florian

Re: [PATCH net-next] net: dsa: b53: Extend platform data to include DSA ports

[Florian Fainelli]

On May 19, 2018 6:42:50 PM PDT, Andrew Lunn  wrote:
>On Sat, May 19, 2018 at 03:55:10PM -0700, Florian Fainelli wrote:
>> Provide a means for !OF platforms to supply their DSA platform data
>> configuration using the dsa_platform_data structure.
>
>Hi Florian
>
>It seems a bit odd adding the header file, but no code. Yes, this will
>help simplify the merge dependencies for the ZII boards next cycle,
>but can we have the actual code as well?

The existing b53_common.c file already makes use of platform data the only 
thing that was missing was a dsa_chip_data structure correctly placed for the 
core DSA layer to obtain port information. This was present from day one in the 
b53 driver because it is also the mechanism used by the bus specific drivers to 
pass information to the core b53 driver file.
Hi Andrew,
-- 
Florian

Re: [PATCH] net: sched: don't disable bh when accessing action idr

[David Miller]

From: Vlad Buslov 
Date: Sat, 19 May 2018 13:12:49 +0300

> 
> On Sat 19 May 2018 at 02:59, Cong Wang  wrote:
>> On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov  wrote:
>>> Underlying implementation of action map has changed and doesn't require
>>> disabling bh anymore. Replace all action idr spinlock usage with regular
>>> calls that do not disable bh.
>>
>> Please explain explicitly why it is not required, don't let people
>> dig, this would save everyone's time.
> 
> Underlying implementation of actions lookup has changed from hashtable
> to idr. Every current action implementation just calls act_api lookup
> function instead of implementing its own lookup. I asked author of idr
> change if there is a reason to continue to use _bh versions and he
> replied that he just left them as-is.

A detailed analysis of the locking requirements both before and
after the IDR changes needs to be in you commit message.

Nobody who reads this from scratch understands all of this background
material, so how can anyone reading your patch review it properly and
understand it?

Re: [PATCH] net: sched: don't disable bh when accessing action idr

[David Miller]

From: Vlad Buslov 
Date: Sat, 19 May 2018 13:12:49 +0300

> 
> On Sat 19 May 2018 at 02:59, Cong Wang  wrote:
>> On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov  wrote:
>>> Underlying implementation of action map has changed and doesn't require
>>> disabling bh anymore. Replace all action idr spinlock usage with regular
>>> calls that do not disable bh.
>>
>> Please explain explicitly why it is not required, don't let people
>> dig, this would save everyone's time.
> 
> Underlying implementation of actions lookup has changed from hashtable
> to idr. Every current action implementation just calls act_api lookup
> function instead of implementing its own lookup. I asked author of idr
> change if there is a reason to continue to use _bh versions and he
> replied that he just left them as-is.

A detailed analysis of the locking requirements both before and
after the IDR changes needs to be in you commit message.

Nobody who reads this from scratch understands all of this background
material, so how can anyone reading your patch review it properly and
understand it?

Re: random: Wake up writers when random pools are zapped

[Herbert Xu]

On Sat, May 19, 2018 at 05:55:19PM -0400, Theodore Y. Ts'o wrote:
>
> Out of curiosity, how/when were you using RNDCLEARPOOL/RNDZAPENTCNT?
> Hopefully it was only testing hw_random drivers, or some such?

I wasn't actually using it myself.  Someone else filed a bug
against RHEL complaining about this and I was just clearing my
decks :)

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: random: Wake up writers when random pools are zapped

[Herbert Xu]

On Sat, May 19, 2018 at 05:55:19PM -0400, Theodore Y. Ts'o wrote:
>
> Out of curiosity, how/when were you using RNDCLEARPOOL/RNDZAPENTCNT?
> Hopefully it was only testing hw_random drivers, or some such?

I wasn't actually using it myself.  Someone else filed a bug
against RHEL complaining about this and I was just clearing my
decks :)

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

[kbuild test robot]

Hi Andrea,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-com20020-Add-com20020-io-mapped-version/20180520-083936
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All warnings (new ones prefixed by >>):

   In file included from drivers/net/arcnet/com20020-isa.c:44:0:
   drivers/net/arcnet/com20020.h: In function 'com20020_set_subaddress':
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020.h:126:3: note: in expansion of macro 
'arcnet_outb'
  arcnet_outb(lp->config, ioaddr, COM20020_REG_W_CONFIG);
  ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020.h:128:3: note: in expansion of macro 
'arcnet_outb'
  arcnet_outb(val, ioaddr, COM20020_REG_W_SUBADR);
  ^~~
   drivers/net/arcnet/com20020-isa.c: In function 'com20020isa_probe':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
>> drivers/net/arcnet/com20020-isa.c:70:6: note: in expansion of macro 
>> 'arcnet_inb'
 if (arcnet_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
 ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/arcdevice.h:88:28: note: in expansion of macro 
'arcnet_inb'
   netdev_warn(dev, fmt, ##__VA_ARGS__);  \
   ^~~
>> drivers/net/arcnet/com20020-isa.c:85:3: note: in expansion of macro 
>> 'arc_printk'
  arc_printk(D_INIT_REASONS, dev, "intmask was %02Xh\n",
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/arcdevice.h:90:28: note: in expansion of macro 
'arcnet_inb'
   netdev_info(dev, fmt, ##__VA_ARGS__);  \
   ^~~
>> drivers/net/arcnet/com20020-isa.c:85:3: note: in expansion of macro 
>> 'arc_printk'
  arc_printk(D_INIT_REASONS, dev, "intmask was %02Xh\n",
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   include/linux/dynamic_debug.h:144:12: note: in expansion of macro 
'arcnet_inb'
 ##__VA_ARGS__);  \
   ^~~
   include/linux/netdevice.h:4419:2: note: in expansion of macro 
'dynamic_netdev_dbg'
 dynamic_netdev_dbg(__dev, format, ##args);  \
 ^~
   drivers/net/arcnet/arcdevice.h:92:4: note: in expansion of macro 'netdev_dbg'
   netdev_dbg(dev, fmt, ##__VA_ARGS__);  \
   ^~
>> drivers/net/arcnet/com20020-isa.c:85:3: note: in expansion of macro 
>> 'arc_printk'
  arc_printk(D_INIT_REASONS, dev, "intmask was %02Xh\n",
  ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
>> drivers/net/arcnet/com20020-isa.c:87:3: note: in expansion of macro 
>> 'arcnet_outb'
  arcnet_outb(0, ioaddr, COM20020_REG_W_INTMASK);
  ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020-isa.c:89:3: note: in expansion of macro 
'arcnet_outb'
  arcnet_outb(NORXflag, ioaddr, COM20020_REG_W_INTMASK);
  ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020-isa.c:91:3: note: in expansion of 

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

[kbuild test robot]

Hi Andrea,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-com20020-Add-com20020-io-mapped-version/20180520-083936
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All warnings (new ones prefixed by >>):

   In file included from drivers/net/arcnet/com20020-isa.c:44:0:
   drivers/net/arcnet/com20020.h: In function 'com20020_set_subaddress':
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020.h:126:3: note: in expansion of macro 
'arcnet_outb'
  arcnet_outb(lp->config, ioaddr, COM20020_REG_W_CONFIG);
  ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020.h:128:3: note: in expansion of macro 
'arcnet_outb'
  arcnet_outb(val, ioaddr, COM20020_REG_W_SUBADR);
  ^~~
   drivers/net/arcnet/com20020-isa.c: In function 'com20020isa_probe':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
>> drivers/net/arcnet/com20020-isa.c:70:6: note: in expansion of macro 
>> 'arcnet_inb'
 if (arcnet_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
 ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/arcdevice.h:88:28: note: in expansion of macro 
'arcnet_inb'
   netdev_warn(dev, fmt, ##__VA_ARGS__);  \
   ^~~
>> drivers/net/arcnet/com20020-isa.c:85:3: note: in expansion of macro 
>> 'arc_printk'
  arc_printk(D_INIT_REASONS, dev, "intmask was %02Xh\n",
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/arcdevice.h:90:28: note: in expansion of macro 
'arcnet_inb'
   netdev_info(dev, fmt, ##__VA_ARGS__);  \
   ^~~
>> drivers/net/arcnet/com20020-isa.c:85:3: note: in expansion of macro 
>> 'arc_printk'
  arc_printk(D_INIT_REASONS, dev, "intmask was %02Xh\n",
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   include/linux/dynamic_debug.h:144:12: note: in expansion of macro 
'arcnet_inb'
 ##__VA_ARGS__);  \
   ^~~
   include/linux/netdevice.h:4419:2: note: in expansion of macro 
'dynamic_netdev_dbg'
 dynamic_netdev_dbg(__dev, format, ##args);  \
 ^~
   drivers/net/arcnet/arcdevice.h:92:4: note: in expansion of macro 'netdev_dbg'
   netdev_dbg(dev, fmt, ##__VA_ARGS__);  \
   ^~
>> drivers/net/arcnet/com20020-isa.c:85:3: note: in expansion of macro 
>> 'arc_printk'
  arc_printk(D_INIT_REASONS, dev, "intmask was %02Xh\n",
  ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
>> drivers/net/arcnet/com20020-isa.c:87:3: note: in expansion of macro 
>> 'arcnet_outb'
  arcnet_outb(0, ioaddr, COM20020_REG_W_INTMASK);
  ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020-isa.c:89:3: note: in expansion of macro 
'arcnet_outb'
  arcnet_outb(NORXflag, ioaddr, COM20020_REG_W_INTMASK);
  ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com20020-isa.c:91:3: note: in expansion of 

Re: [PATCH net-next] net: mvpp2: Add missing VLAN tag detection

[David Miller]

From: Maxime Chevallier 
Date: Fri, 18 May 2018 09:33:39 +0200

> Marvell PPv2 Header Parser sets some bits in the 'result_info' field in
> each lookup iteration, to identify different packet attributes such as
> DSA / VLAN tag, protocol infos, etc. This is used in further
> classification stages in the controller.
> 
> It's the DSA tag detection entry that is in charge of detecting when there
> is a single VLAN tag.
> 
> This commits adds the missing update of the result_info in this case.
> 
> Signed-off-by: Maxime Chevallier 

Applied, thanks.

Re: [PATCH net-next] net: mvpp2: Add missing VLAN tag detection

[David Miller]

From: Maxime Chevallier 
Date: Fri, 18 May 2018 09:33:39 +0200

> Marvell PPv2 Header Parser sets some bits in the 'result_info' field in
> each lookup iteration, to identify different packet attributes such as
> DSA / VLAN tag, protocol infos, etc. This is used in further
> classification stages in the controller.
> 
> It's the DSA tag detection entry that is in charge of detecting when there
> is a single VLAN tag.
> 
> This commits adds the missing update of the result_info in this case.
> 
> Signed-off-by: Maxime Chevallier 

Applied, thanks.

[GIT PULL] arm64: dts: uniphier: UniPhier DT updates for v4.18

[Masahiro Yamada]

Hi Arnd, Olof,

Here are UniPhier DT (64bit) updates for the v4.18 merge window.
Please pull!


The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt64-v4.18

for you to fetch changes up to b076ff8bddfba793d49bca14feb49a0e84f41843:

  arm64: dts: uniphier: add syscon-phy-mode property to each ethernet
node (2018-04-25 00:21:14 +0900)


UniPhier ARM64 SoC DT updates for v4.18

- add more properties to ethernet nodes


Kunihiko Hayashi (2):
  arm64: dts: uniphier: add clock-names and reset-names to ethernet node
  arm64: dts: uniphier: add syscon-phy-mode property to each ethernet node

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 5 -
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 3 +++
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 8 +++-
 3 files changed, 14 insertions(+), 2 deletions(-)


-- 
Best Regards
Masahiro Yamada

[GIT PULL] arm64: dts: uniphier: UniPhier DT updates for v4.18

[Masahiro Yamada]

Hi Arnd, Olof,

Here are UniPhier DT (64bit) updates for the v4.18 merge window.
Please pull!


The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt64-v4.18

for you to fetch changes up to b076ff8bddfba793d49bca14feb49a0e84f41843:

  arm64: dts: uniphier: add syscon-phy-mode property to each ethernet
node (2018-04-25 00:21:14 +0900)


UniPhier ARM64 SoC DT updates for v4.18

- add more properties to ethernet nodes


Kunihiko Hayashi (2):
  arm64: dts: uniphier: add clock-names and reset-names to ethernet node
  arm64: dts: uniphier: add syscon-phy-mode property to each ethernet node

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 5 -
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 3 +++
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 8 +++-
 3 files changed, 14 insertions(+), 2 deletions(-)


-- 
Best Regards
Masahiro Yamada

[PATCH V3] scsi: ufs: Add specific callback for setting DMA mask

[Alim Akhtar]

Currently DMA mask for UFS HCI is set by reading CAP register's
[64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
This works perfectly fine with DMA mask set as 64 in case there is no
IOMMU attached to HCI.
In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
work as HCI has only 36bit addressing and SMMU has created mapping of
64 bit and as the device truncates the address, its mapping will not
be found by iommu.
To resolve such issues, let the variant driver sets its own DMA mask.

Signed-off-by: Alim Akhtar 
---
 drivers/scsi/ufs/ufshcd.c | 3 +++
 drivers/scsi/ufs/ufshcd.h | 2 ++
 2 files changed, 5 insertions(+)

I am not sure if there are other ways available to handle such cases.
The IOMMU I am talking about is arm-smmu and it DT binding does not
give much idea about handling such cases.
Have tested this patch with HCI controller with IOMMU attached.

Changes Since V1: 
- Fixed build issue as reported by Kbuild test robot.

Changes Since V2: 
- Remove RFC tag as suggested by Subhash.

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..9a1374e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
  */
 static int ufshcd_set_dma_mask(struct ufs_hba *hba)
 {
+   if (hba->vops && hba->vops->set_dma_mask)
+   return hba->vops->set_dma_mask(hba);
+
if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
return 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 1332e54..89c6dae 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
  * @resume: called during host controller PM callback
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
+ * @set_dma_mask: used to set variant specific DMA mask
  */
 struct ufs_hba_variant_ops {
const char *name;
@@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+   int (*set_dma_mask)(struct ufs_hba *hba);
 };
 
 /* clock gating state  */
-- 
2.7.4

[PATCH V3] scsi: ufs: Add specific callback for setting DMA mask

[Alim Akhtar]

Currently DMA mask for UFS HCI is set by reading CAP register's
[64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
This works perfectly fine with DMA mask set as 64 in case there is no
IOMMU attached to HCI.
In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
work as HCI has only 36bit addressing and SMMU has created mapping of
64 bit and as the device truncates the address, its mapping will not
be found by iommu.
To resolve such issues, let the variant driver sets its own DMA mask.

Signed-off-by: Alim Akhtar 
---
 drivers/scsi/ufs/ufshcd.c | 3 +++
 drivers/scsi/ufs/ufshcd.h | 2 ++
 2 files changed, 5 insertions(+)

I am not sure if there are other ways available to handle such cases.
The IOMMU I am talking about is arm-smmu and it DT binding does not
give much idea about handling such cases.
Have tested this patch with HCI controller with IOMMU attached.

Changes Since V1: 
- Fixed build issue as reported by Kbuild test robot.

Changes Since V2: 
- Remove RFC tag as suggested by Subhash.

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..9a1374e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
  */
 static int ufshcd_set_dma_mask(struct ufs_hba *hba)
 {
+   if (hba->vops && hba->vops->set_dma_mask)
+   return hba->vops->set_dma_mask(hba);
+
if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
return 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 1332e54..89c6dae 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
  * @resume: called during host controller PM callback
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
+ * @set_dma_mask: used to set variant specific DMA mask
  */
 struct ufs_hba_variant_ops {
const char *name;
@@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+   int (*set_dma_mask)(struct ufs_hba *hba);
 };
 
 /* clock gating state  */
-- 
2.7.4

[GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.18

[Masahiro Yamada]

Hi Arnd, Olof,

Here are UniPhier DT (32bit) updates for the v4.18 merge window.
Please pull!


The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt-v4.18

for you to fetch changes up to 526f872b8492fbfb1a0f342e601bdc5ba322f16b:

  ARM: dts: uniphier: add syscon-phy-mode property to each ethernet
node (2018-04-25 00:21:51 +0900)


UniPhier ARM SoC DT updates for v4.18

- add more properties to ethernet nodes


Kunihiko Hayashi (2):
  ARM: dts: uniphier: add required clocks and resets to Pro4 ethernet node
  ARM: dts: uniphier: add syscon-phy-mode property to each ethernet node

 arch/arm/boot/dts/uniphier-pro4.dtsi | 10 +++---
 arch/arm/boot/dts/uniphier-pxs2.dtsi |  3 +++
 2 files changed, 10 insertions(+), 3 deletions(-)



-- 
Best Regards
Masahiro Yamada

[GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.18

[Masahiro Yamada]

Hi Arnd, Olof,

Here are UniPhier DT (32bit) updates for the v4.18 merge window.
Please pull!


The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt-v4.18

for you to fetch changes up to 526f872b8492fbfb1a0f342e601bdc5ba322f16b:

  ARM: dts: uniphier: add syscon-phy-mode property to each ethernet
node (2018-04-25 00:21:51 +0900)


UniPhier ARM SoC DT updates for v4.18

- add more properties to ethernet nodes


Kunihiko Hayashi (2):
  ARM: dts: uniphier: add required clocks and resets to Pro4 ethernet node
  ARM: dts: uniphier: add syscon-phy-mode property to each ethernet node

 arch/arm/boot/dts/uniphier-pro4.dtsi | 10 +++---
 arch/arm/boot/dts/uniphier-pxs2.dtsi |  3 +++
 2 files changed, 10 insertions(+), 3 deletions(-)



-- 
Best Regards
Masahiro Yamada

Re: [PATCH V3] scsi: ufs: Add specific callback for setting DMA mask

[Alim Akhtar]

Hi All
Please ignore the below patch, sorry for the noise.
Will send updated patch soon.

Regards,
Alim

On 05/20/2018 07:41 AM, Bharat Uppal wrote:
> From: Alim Akhtar 
> 
> Currently DMA mask for UFS HCI is set by reading CAP register's
> [64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
> This works perfectly fine with DMA mask set as 64 in case there is no
> IOMMU attached to HCI.
> In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
> work as HCI has only 36bit addressing and SMMU has created mapping of
> 64 bit and as the device truncates the address, its mapping will not
> be found by iommu.
> To resolve such issues, let the variant driver sets its own DMA mask.
> 
> Signed-off-by: Alim Akhtar 
> ---
>   drivers/scsi/ufs/ufshcd.c | 3 +++
>   drivers/scsi/ufs/ufshcd.h | 2 ++
>   2 files changed, 5 insertions(+)
> 
> I am not sure if there are other ways available to handle such cases.
> The IOMMU I am talking about is arm-smmu and it DT binding does not
> give much idea about handling such cases.
> Have tested this patch with HCI controller with IOMMU attached.
> 
> Changes Since V1:
>   - Fixed build issue as reported by Kbuild test robot.
> 
> Changes Since V2:
>   - Remove RFC tag as suggested by Subhash.
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index a355d98..9a1374e 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
>*/
>   static int ufshcd_set_dma_mask(struct ufs_hba *hba)
>   {
> + if (hba->vops && hba->vops->set_dma_mask)
> + return hba->vops->set_dma_mask(hba);
> +
>   if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
>   if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
>   return 0;
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 1332e54..89c6dae 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
>* @resume: called during host controller PM callback
>* @dbg_register_dump: used to dump controller debug information
>* @phy_initialization: used to initialize phys
> + * @set_dma_mask: used to set variant specific DMA mask
>*/
>   struct ufs_hba_variant_ops {
>   const char *name;
> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
>   int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>   void(*dbg_register_dump)(struct ufs_hba *hba);
>   int (*phy_initialization)(struct ufs_hba *);
> + int (*set_dma_mask)(struct ufs_hba *hba);
>   };
>   
>   /* clock gating state  */
> 

Re: [PATCH V3] scsi: ufs: Add specific callback for setting DMA mask

[Alim Akhtar]

Hi All
Please ignore the below patch, sorry for the noise.
Will send updated patch soon.

Regards,
Alim

On 05/20/2018 07:41 AM, Bharat Uppal wrote:
> From: Alim Akhtar 
> 
> Currently DMA mask for UFS HCI is set by reading CAP register's
> [64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
> This works perfectly fine with DMA mask set as 64 in case there is no
> IOMMU attached to HCI.
> In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
> work as HCI has only 36bit addressing and SMMU has created mapping of
> 64 bit and as the device truncates the address, its mapping will not
> be found by iommu.
> To resolve such issues, let the variant driver sets its own DMA mask.
> 
> Signed-off-by: Alim Akhtar 
> ---
>   drivers/scsi/ufs/ufshcd.c | 3 +++
>   drivers/scsi/ufs/ufshcd.h | 2 ++
>   2 files changed, 5 insertions(+)
> 
> I am not sure if there are other ways available to handle such cases.
> The IOMMU I am talking about is arm-smmu and it DT binding does not
> give much idea about handling such cases.
> Have tested this patch with HCI controller with IOMMU attached.
> 
> Changes Since V1:
>   - Fixed build issue as reported by Kbuild test robot.
> 
> Changes Since V2:
>   - Remove RFC tag as suggested by Subhash.
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index a355d98..9a1374e 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
>*/
>   static int ufshcd_set_dma_mask(struct ufs_hba *hba)
>   {
> + if (hba->vops && hba->vops->set_dma_mask)
> + return hba->vops->set_dma_mask(hba);
> +
>   if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
>   if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
>   return 0;
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 1332e54..89c6dae 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
>* @resume: called during host controller PM callback
>* @dbg_register_dump: used to dump controller debug information
>* @phy_initialization: used to initialize phys
> + * @set_dma_mask: used to set variant specific DMA mask
>*/
>   struct ufs_hba_variant_ops {
>   const char *name;
> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
>   int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>   void(*dbg_register_dump)(struct ufs_hba *hba);
>   int (*phy_initialization)(struct ufs_hba *);
> + int (*set_dma_mask)(struct ufs_hba *hba);
>   };
>   
>   /* clock gating state  */
> 

[PATCH V3] scsi: ufs: Add specific callback for setting DMA mask

[Bharat Uppal]

From: Alim Akhtar 

Currently DMA mask for UFS HCI is set by reading CAP register's
[64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
This works perfectly fine with DMA mask set as 64 in case there is no
IOMMU attached to HCI.
In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
work as HCI has only 36bit addressing and SMMU has created mapping of
64 bit and as the device truncates the address, its mapping will not
be found by iommu.
To resolve such issues, let the variant driver sets its own DMA mask.

Signed-off-by: Alim Akhtar 
---
 drivers/scsi/ufs/ufshcd.c | 3 +++
 drivers/scsi/ufs/ufshcd.h | 2 ++
 2 files changed, 5 insertions(+)

I am not sure if there are other ways available to handle such cases.
The IOMMU I am talking about is arm-smmu and it DT binding does not
give much idea about handling such cases.
Have tested this patch with HCI controller with IOMMU attached.

Changes Since V1: 
- Fixed build issue as reported by Kbuild test robot.

Changes Since V2: 
- Remove RFC tag as suggested by Subhash.

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..9a1374e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
  */
 static int ufshcd_set_dma_mask(struct ufs_hba *hba)
 {
+   if (hba->vops && hba->vops->set_dma_mask)
+   return hba->vops->set_dma_mask(hba);
+
if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
return 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 1332e54..89c6dae 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
  * @resume: called during host controller PM callback
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
+ * @set_dma_mask: used to set variant specific DMA mask
  */
 struct ufs_hba_variant_ops {
const char *name;
@@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+   int (*set_dma_mask)(struct ufs_hba *hba);
 };
 
 /* clock gating state  */
-- 
2.7.4

[PATCH V3] scsi: ufs: Add specific callback for setting DMA mask

[Bharat Uppal]

From: Alim Akhtar 

Currently DMA mask for UFS HCI is set by reading CAP register's
[64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
This works perfectly fine with DMA mask set as 64 in case there is no
IOMMU attached to HCI.
In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
work as HCI has only 36bit addressing and SMMU has created mapping of
64 bit and as the device truncates the address, its mapping will not
be found by iommu.
To resolve such issues, let the variant driver sets its own DMA mask.

Signed-off-by: Alim Akhtar 
---
 drivers/scsi/ufs/ufshcd.c | 3 +++
 drivers/scsi/ufs/ufshcd.h | 2 ++
 2 files changed, 5 insertions(+)

I am not sure if there are other ways available to handle such cases.
The IOMMU I am talking about is arm-smmu and it DT binding does not
give much idea about handling such cases.
Have tested this patch with HCI controller with IOMMU attached.

Changes Since V1: 
- Fixed build issue as reported by Kbuild test robot.

Changes Since V2: 
- Remove RFC tag as suggested by Subhash.

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..9a1374e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
  */
 static int ufshcd_set_dma_mask(struct ufs_hba *hba)
 {
+   if (hba->vops && hba->vops->set_dma_mask)
+   return hba->vops->set_dma_mask(hba);
+
if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
return 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 1332e54..89c6dae 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
  * @resume: called during host controller PM callback
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
+ * @set_dma_mask: used to set variant specific DMA mask
  */
 struct ufs_hba_variant_ops {
const char *name;
@@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+   int (*set_dma_mask)(struct ufs_hba *hba);
 };
 
 /* clock gating state  */
-- 
2.7.4

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

[kbuild test robot]

Hi Andrea,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-com20020-Add-com20020-io-mapped-version/20180520-083936
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/com90xx.c: In function 'com90xx_probe':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:161:7: note: in expansion of macro 'arcnet_inb'
  if (arcnet_inb(ioaddr, COM9026_REG_R_STATUS) == 0xFF) {
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:171:3: note: in expansion of macro 'arcnet_inb'
  arcnet_inb(ioaddr, COM9026_REG_R_RESET);
  ^~
>> drivers/net/arcnet/com90xx.c:233:7: error: implicit declaration of function 
>> 'arcnet_readb'; did you mean 'arcnet_outsb'? 
>> [-Werror=implicit-function-declaration]
  if (arcnet_readb(base, COM9026_REG_R_STATUS) != TESTvalue) {
  ^~~~
  arcnet_outsb
>> drivers/net/arcnet/com90xx.c:247:3: error: implicit declaration of function 
>> 'arcnet_writeb'; did you mean 'arcnet_outsb'? 
>> [-Werror=implicit-function-declaration]
  arcnet_writeb(0x42, base, COM9026_REG_W_INTMASK);
  ^
  arcnet_outsb
   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:312:12: note: in expansion of macro 'arcnet_inb'
  status = arcnet_inb(ioaddr, COM9026_REG_R_STATUS);
   ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:324:3: note: in expansion of macro 'arcnet_outb'
  arcnet_outb(CFLAGScmd | RESETclear | CONFIGclear,
  ^~~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:326:12: note: in expansion of macro 'arcnet_inb'
  status = arcnet_inb(ioaddr, COM9026_REG_R_STATUS);
   ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:346:4: note: in expansion of macro 'arcnet_outb'
   arcnet_outb(NORXflag, ioaddr, COM9026_REG_W_INTMASK);
   ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:348:4: note: in expansion of macro 'arcnet_outb'
   arcnet_outb(0, ioaddr, COM9026_REG_W_INTMASK);
   ^~~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:383:3: note: in expansion of macro 'arcnet_inb'
  arcnet_inb(ioaddr, COM9026_REG_R_RESET);
  ^~
   drivers/net/arcnet/com90xx.c: In function 'com90xx_command':
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:565:2: note: in expansion of macro 'arcnet_outb'
 arcnet_outb(cmd, ioaddr, COM9026_REG_W_COMMAND);
 ^~~
   drivers/net/arcnet/com90xx.c: In function 'com90xx_status':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:572:9: note: in expansion of macro 'arcnet_inb'
 return arcnet_inb(ioaddr, 

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

[kbuild test robot]

Hi Andrea,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-com20020-Add-com20020-io-mapped-version/20180520-083936
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/com90xx.c: In function 'com90xx_probe':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:161:7: note: in expansion of macro 'arcnet_inb'
  if (arcnet_inb(ioaddr, COM9026_REG_R_STATUS) == 0xFF) {
  ^~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:171:3: note: in expansion of macro 'arcnet_inb'
  arcnet_inb(ioaddr, COM9026_REG_R_RESET);
  ^~
>> drivers/net/arcnet/com90xx.c:233:7: error: implicit declaration of function 
>> 'arcnet_readb'; did you mean 'arcnet_outsb'? 
>> [-Werror=implicit-function-declaration]
  if (arcnet_readb(base, COM9026_REG_R_STATUS) != TESTvalue) {
  ^~~~
  arcnet_outsb
>> drivers/net/arcnet/com90xx.c:247:3: error: implicit declaration of function 
>> 'arcnet_writeb'; did you mean 'arcnet_outsb'? 
>> [-Werror=implicit-function-declaration]
  arcnet_writeb(0x42, base, COM9026_REG_W_INTMASK);
  ^
  arcnet_outsb
   In file included from drivers/net/arcnet/com90xx.c:40:0:
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:312:12: note: in expansion of macro 'arcnet_inb'
  status = arcnet_inb(ioaddr, COM9026_REG_R_STATUS);
   ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:324:3: note: in expansion of macro 'arcnet_outb'
  arcnet_outb(CFLAGScmd | RESETclear | CONFIGclear,
  ^~~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:326:12: note: in expansion of macro 'arcnet_inb'
  status = arcnet_inb(ioaddr, COM9026_REG_R_STATUS);
   ^~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:346:4: note: in expansion of macro 'arcnet_outb'
   arcnet_outb(NORXflag, ioaddr, COM9026_REG_W_INTMASK);
   ^~~
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:348:4: note: in expansion of macro 'arcnet_outb'
   arcnet_outb(0, ioaddr, COM9026_REG_W_INTMASK);
   ^~~
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:383:3: note: in expansion of macro 'arcnet_inb'
  arcnet_inb(ioaddr, COM9026_REG_R_RESET);
  ^~
   drivers/net/arcnet/com90xx.c: In function 'com90xx_command':
   drivers/net/arcnet/arcdevice.h:379:18: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 iowrite8(value, (void __iomem *)addr + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:565:2: note: in expansion of macro 'arcnet_outb'
 arcnet_outb(cmd, ioaddr, COM9026_REG_W_COMMAND);
 ^~~
   drivers/net/arcnet/com90xx.c: In function 'com90xx_status':
   drivers/net/arcnet/arcdevice.h:376:10: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 ioread8((void __iomem *)(addr) + BUS_ALIGN * offset)
 ^
   drivers/net/arcnet/com90xx.c:572:9: note: in expansion of macro 'arcnet_inb'
 return arcnet_inb(ioaddr, 

Re: [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs

[Julian Calaby]

Hi Jernej,

On Sun, May 20, 2018 at 11:57 AM, Julian Calaby  wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec  
> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can be
>> connected to 2 different TCONs (out of 4) and mixers can be connected to
>> any TCON. All this must be configured in TCON TOP.
>>
>> Along with definition of TCON capabilities also add mux callback, which
>> can configure this complex pipeline.
>>
>> For now, only TCON TV is supported.
>>
>> Signed-off-by: Jernej Skrabec 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index e0c562ce1c22..81b9551e4f78 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
>> return 0;
>>  }
>>
>> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
>> +const struct drm_encoder *encoder,
>> +int index)
>> +{
>> +   if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
>> +   sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
>> +
>> +   sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
>> +tcon_type_tv, index);
>> +
>> +   return 0;
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
>> +  const struct drm_encoder *encoder)
>> +{
>> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
>> +  const struct drm_encoder *encoder)
>> +{
>> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
>> +}
>
> Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
> If so, maybe we should add an index to the TCON quirks and have a
> common TCON-TOP set_mux function.

Actually, that only moves it up a level. Should it be a devicetree property?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs

[Julian Calaby]

Hi Jernej,

On Sun, May 20, 2018 at 11:57 AM, Julian Calaby  wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec  
> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can be
>> connected to 2 different TCONs (out of 4) and mixers can be connected to
>> any TCON. All this must be configured in TCON TOP.
>>
>> Along with definition of TCON capabilities also add mux callback, which
>> can configure this complex pipeline.
>>
>> For now, only TCON TV is supported.
>>
>> Signed-off-by: Jernej Skrabec 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index e0c562ce1c22..81b9551e4f78 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
>> return 0;
>>  }
>>
>> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
>> +const struct drm_encoder *encoder,
>> +int index)
>> +{
>> +   if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
>> +   sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
>> +
>> +   sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
>> +tcon_type_tv, index);
>> +
>> +   return 0;
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
>> +  const struct drm_encoder *encoder)
>> +{
>> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
>> +  const struct drm_encoder *encoder)
>> +{
>> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
>> +}
>
> Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
> If so, maybe we should add an index to the TCON quirks and have a
> common TCON-TOP set_mux function.

Actually, that only moves it up a level. Should it be a devicetree property?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: INFO: task hung in tls_push_record

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:eb38401c779d net: stmmac: Populate missing callbacks in HW..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16d0820f80
kernel config:  https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=4006516aae0b06e7050f
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10f6927b80
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15b7a20f80

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4006516aae0b06e70...@syzkaller.appspotmail.com

INFO: task syz-executor793:4489 blocked for more than 120 seconds.
  Not tainted 4.17.0-rc4+ #52
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor793 D23464  4489   4486 0x
Call Trace:
 context_switch kernel/sched/core.c:2848 [inline]
 __schedule+0x801/0x1e30 kernel/sched/core.c:3490
 schedule+0xef/0x430 kernel/sched/core.c:3549
 schedule_timeout+0x1b5/0x240 kernel/time/timer.c:1777
 do_wait_for_common kernel/sched/completion.c:83 [inline]
 __wait_for_common kernel/sched/completion.c:104 [inline]
 wait_for_common kernel/sched/completion.c:115 [inline]
 wait_for_completion+0x3e7/0x870 kernel/sched/completion.c:136
 crypto_wait_req include/linux/crypto.h:512 [inline]
 tls_do_encryption net/tls/tls_sw.c:217 [inline]
 tls_push_record+0xedc/0x13e0 net/tls/tls_sw.c:248
 tls_sw_sendmsg+0x8d7/0x12b0 net/tls/tls_sw.c:440
 inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 __sys_sendto+0x3d7/0x670 net/socket.c:1789
 __do_sys_sendto net/socket.c:1801 [inline]
 __se_sys_sendto net/socket.c:1797 [inline]
 __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4457d9
RSP: 002b:7fa388d06da8 EFLAGS: 0216 ORIG_RAX: 002c
RAX: ffda RBX: 006dac24 RCX: 004457d9
RDX: fdef RSI: 25c0 RDI: 0022
RBP: 006dac20 R08: 2000 R09: 001c
R10:  R11: 0216 R12: 
R13: 7ffd5148ecaf R14: 7fa388d079c0 R15: 0001

Showing all locks held in the system:
2 locks held by khungtaskd/892:
 #0: 9dfaae0c (rcu_read_lock){}, at:  
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
 #0: 9dfaae0c (rcu_read_lock){}, at: watchdog+0x1ff/0xf60  
kernel/hung_task.c:249
 #1: 58f79a8d (tasklist_lock){.+.+}, at:  
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470

1 lock held by rsyslogd/4370:
 #0: 59c3c7ae (>f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0  
fs/file.c:766

2 locks held by getty/4460:
 #0: e25a52c3 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 2caea50f (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4461:
 #0: d38c9806 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: eaffe99d (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4462:
 #0: cec6abe7 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 00afd91c (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4463:
 #0: 3456fca5 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 38a65d91 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4464:
 #0: 01e783b1 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 3ecd2e34 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4465:
 #0: 7ef8b451 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 6996c3ed (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4466:
 #0: d15d9a92 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: ee44bcf4 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

1 lock held by syz-executor793/4489:
 #0: 08c84b0d (sk_lock-AF_INET6){+.+.}, at: lock_sock  
include/net/sock.h:1474 [inline]
 #0: 08c84b0d (sk_lock-AF_INET6){+.+.}, at:  
tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384

1 lock held by syz-executor793/4494:
 #0: f2de7555 (sk_lock-AF_INET6){+.+.}, at: lock_sock  
include/net/sock.h:1474 [inline]
 #0: f2de7555 

Re: INFO: task hung in tls_push_record

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:eb38401c779d net: stmmac: Populate missing callbacks in HW..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16d0820f80
kernel config:  https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=4006516aae0b06e7050f
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10f6927b80
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15b7a20f80

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4006516aae0b06e70...@syzkaller.appspotmail.com

INFO: task syz-executor793:4489 blocked for more than 120 seconds.
  Not tainted 4.17.0-rc4+ #52
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor793 D23464  4489   4486 0x
Call Trace:
 context_switch kernel/sched/core.c:2848 [inline]
 __schedule+0x801/0x1e30 kernel/sched/core.c:3490
 schedule+0xef/0x430 kernel/sched/core.c:3549
 schedule_timeout+0x1b5/0x240 kernel/time/timer.c:1777
 do_wait_for_common kernel/sched/completion.c:83 [inline]
 __wait_for_common kernel/sched/completion.c:104 [inline]
 wait_for_common kernel/sched/completion.c:115 [inline]
 wait_for_completion+0x3e7/0x870 kernel/sched/completion.c:136
 crypto_wait_req include/linux/crypto.h:512 [inline]
 tls_do_encryption net/tls/tls_sw.c:217 [inline]
 tls_push_record+0xedc/0x13e0 net/tls/tls_sw.c:248
 tls_sw_sendmsg+0x8d7/0x12b0 net/tls/tls_sw.c:440
 inet_sendmsg+0x19f/0x690 net/ipv4/af_inet.c:798
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg+0xd5/0x120 net/socket.c:639
 __sys_sendto+0x3d7/0x670 net/socket.c:1789
 __do_sys_sendto net/socket.c:1801 [inline]
 __se_sys_sendto net/socket.c:1797 [inline]
 __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1797
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4457d9
RSP: 002b:7fa388d06da8 EFLAGS: 0216 ORIG_RAX: 002c
RAX: ffda RBX: 006dac24 RCX: 004457d9
RDX: fdef RSI: 25c0 RDI: 0022
RBP: 006dac20 R08: 2000 R09: 001c
R10:  R11: 0216 R12: 
R13: 7ffd5148ecaf R14: 7fa388d079c0 R15: 0001

Showing all locks held in the system:
2 locks held by khungtaskd/892:
 #0: 9dfaae0c (rcu_read_lock){}, at:  
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
 #0: 9dfaae0c (rcu_read_lock){}, at: watchdog+0x1ff/0xf60  
kernel/hung_task.c:249
 #1: 58f79a8d (tasklist_lock){.+.+}, at:  
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470

1 lock held by rsyslogd/4370:
 #0: 59c3c7ae (>f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0  
fs/file.c:766

2 locks held by getty/4460:
 #0: e25a52c3 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 2caea50f (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4461:
 #0: d38c9806 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: eaffe99d (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4462:
 #0: cec6abe7 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 00afd91c (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4463:
 #0: 3456fca5 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 38a65d91 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4464:
 #0: 01e783b1 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 3ecd2e34 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4465:
 #0: 7ef8b451 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: 6996c3ed (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

2 locks held by getty/4466:
 #0: d15d9a92 (>ldisc_sem){}, at:  
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
 #1: ee44bcf4 (>atomic_read_lock){+.+.}, at:  
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131

1 lock held by syz-executor793/4489:
 #0: 08c84b0d (sk_lock-AF_INET6){+.+.}, at: lock_sock  
include/net/sock.h:1474 [inline]
 #0: 08c84b0d (sk_lock-AF_INET6){+.+.}, at:  
tls_sw_sendmsg+0x1b9/0x12b0 net/tls/tls_sw.c:384

1 lock held by syz-executor793/4494:
 #0: f2de7555 (sk_lock-AF_INET6){+.+.}, at: lock_sock  
include/net/sock.h:1474 [inline]
 #0: f2de7555 

Re: [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs

[Julian Calaby]

Hi Jernej,

On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec  wrote:
> R40 display pipeline has a lot of possible configurations. HDMI can be
> connected to 2 different TCONs (out of 4) and mixers can be connected to
> any TCON. All this must be configured in TCON TOP.
>
> Along with definition of TCON capabilities also add mux callback, which
> can configure this complex pipeline.
>
> For now, only TCON TV is supported.
>
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++
>  1 file changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index e0c562ce1c22..81b9551e4f78 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
> return 0;
>  }
>
> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
> +const struct drm_encoder *encoder,
> +int index)
> +{
> +   if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
> +   sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
> +
> +   sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
> +tcon_type_tv, index);
> +
> +   return 0;
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
> +  const struct drm_encoder *encoder)
> +{
> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
> +  const struct drm_encoder *encoder)
> +{
> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
> +}

Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
If so, maybe we should add an index to the TCON quirks and have a
common TCON-TOP set_mux function.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs

[Julian Calaby]

Hi Jernej,

On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec  wrote:
> R40 display pipeline has a lot of possible configurations. HDMI can be
> connected to 2 different TCONs (out of 4) and mixers can be connected to
> any TCON. All this must be configured in TCON TOP.
>
> Along with definition of TCON capabilities also add mux callback, which
> can configure this complex pipeline.
>
> For now, only TCON TV is supported.
>
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++
>  1 file changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index e0c562ce1c22..81b9551e4f78 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
> return 0;
>  }
>
> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
> +const struct drm_encoder *encoder,
> +int index)
> +{
> +   if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
> +   sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
> +
> +   sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
> +tcon_type_tv, index);
> +
> +   return 0;
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
> +  const struct drm_encoder *encoder)
> +{
> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
> +  const struct drm_encoder *encoder)
> +{
> +   return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
> +}

Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
If so, maybe we should add an index to the TCON quirks and have a
common TCON-TOP set_mux function.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCHv2][SMB3] Add kernel trace support

[Steve French]

On Sat, May 19, 2018 at 6:22 PM, Dave Chinner  wrote:
> On Fri, May 18, 2018 at 01:43:14PM -0700, Steve French wrote:
>> On Fri, May 18, 2018 at 11:46 AM, Ralph Böhme  wrote:
>> > On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical 
>> > wrote:
>> >> Patch updated with additional tracepoint locations and some formatting
>> >> improvements. There are some obvious additional tracepoints that could
>> >> be added, but this should be a reasonable group to start with.
>> >>
>> >> From edc02d6f9dc24963d510c7ef59067428d3b082d3 Mon Sep 17 00:00:00 2001
>> >> From: Steve French 
>> >> Date: Thu, 17 May 2018 21:16:55 -0500
>> >> Subject: [PATCH] smb3: Add ftrace tracepoints for improved SMB3 debugging
>> >>
>> >> Although dmesg logs and wireshark network traces can be
>> >> helpful, being able to dynamically enable/disable tracepoints
>> >> (in this case via the kernel ftrace mechanism) can also be
>> >> helpful in more quickly debugging problems, and more
>> >> selectively tracing the events related to the bug report.
>> >>
>> >> This patch adds 12 ftrace tracepoints to cifs.ko for SMB3 events
>> >> in some obvious locations.  Subsequent patches will add more
>> >> as needed.
>> >>
>> >> Example use:
>> >>trace-cmd record -e cifs
>> >>
>> >>trace-cmd show
>> >
>> > pardon my ignorance, but are these tracepoints usable with other tracing
>> > frameworks like Systemtap?
>> >
>> > Last time I checked, Systemtap looked like *the* tool.
>
> Systemtap is great when you have a need for custom tracing. But for
> day-to-day kernel development, tracepoints are far more useful
> because they are always there and can cover all the common
> situations that you need to trace.
>
> And when it comes to debugging a one-off user problem when the user
> knows nothing about systemtap?  Nothing beats asking the user
> to run a trace on built-in tracepoints, reproduce the problem and
> send the trace report back as per the above example.

Yep - it has already been helpful in debugging problems.

Main problem I hit using the new tracepoints over the past few days
was entries being discarded from the buffer - I had a counter leak (now
fixed) that xfstest showed ... but about 90% of the entries were dropped.
Tried increasing buffer size but might have made things worse not better.
Ideas how to force more entries to be saved?

>> > Is there a generic trace
>> > point infrastructure that tracing tools can consume, so we're not tied to
>> > ftrace?
>>
>> At the kernel filesystem/mm summit a few recommended using ftrace
>> (trace-cmd).  Don't know what
>> the thinking is about this vs. systemtap these days.  There was a nice
>> three part series
>> describing ftrace/trace-cmd on lwn
>> (https://old.lwn.net/Articles/365835/) a while ago.
>>
>> In terms of useability "trace-cmd" looked good to me and much more
>> powerful than the
>> current dmesg based printk style debugging.
>
> And then you learn about trace_printk() for putting custom one-off
> debug into the tracepoint stream and wonder why you didn't know
> about this years ago :P

Thanks for the pointers at the summit ...



-- 
Thanks,

Steve

Re: [PATCHv2][SMB3] Add kernel trace support

[Steve French]

On Sat, May 19, 2018 at 6:22 PM, Dave Chinner  wrote:
> On Fri, May 18, 2018 at 01:43:14PM -0700, Steve French wrote:
>> On Fri, May 18, 2018 at 11:46 AM, Ralph Böhme  wrote:
>> > On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical 
>> > wrote:
>> >> Patch updated with additional tracepoint locations and some formatting
>> >> improvements. There are some obvious additional tracepoints that could
>> >> be added, but this should be a reasonable group to start with.
>> >>
>> >> From edc02d6f9dc24963d510c7ef59067428d3b082d3 Mon Sep 17 00:00:00 2001
>> >> From: Steve French 
>> >> Date: Thu, 17 May 2018 21:16:55 -0500
>> >> Subject: [PATCH] smb3: Add ftrace tracepoints for improved SMB3 debugging
>> >>
>> >> Although dmesg logs and wireshark network traces can be
>> >> helpful, being able to dynamically enable/disable tracepoints
>> >> (in this case via the kernel ftrace mechanism) can also be
>> >> helpful in more quickly debugging problems, and more
>> >> selectively tracing the events related to the bug report.
>> >>
>> >> This patch adds 12 ftrace tracepoints to cifs.ko for SMB3 events
>> >> in some obvious locations.  Subsequent patches will add more
>> >> as needed.
>> >>
>> >> Example use:
>> >>trace-cmd record -e cifs
>> >>
>> >>trace-cmd show
>> >
>> > pardon my ignorance, but are these tracepoints usable with other tracing
>> > frameworks like Systemtap?
>> >
>> > Last time I checked, Systemtap looked like *the* tool.
>
> Systemtap is great when you have a need for custom tracing. But for
> day-to-day kernel development, tracepoints are far more useful
> because they are always there and can cover all the common
> situations that you need to trace.
>
> And when it comes to debugging a one-off user problem when the user
> knows nothing about systemtap?  Nothing beats asking the user
> to run a trace on built-in tracepoints, reproduce the problem and
> send the trace report back as per the above example.

Yep - it has already been helpful in debugging problems.

Main problem I hit using the new tracepoints over the past few days
was entries being discarded from the buffer - I had a counter leak (now
fixed) that xfstest showed ... but about 90% of the entries were dropped.
Tried increasing buffer size but might have made things worse not better.
Ideas how to force more entries to be saved?

>> > Is there a generic trace
>> > point infrastructure that tracing tools can consume, so we're not tied to
>> > ftrace?
>>
>> At the kernel filesystem/mm summit a few recommended using ftrace
>> (trace-cmd).  Don't know what
>> the thinking is about this vs. systemtap these days.  There was a nice
>> three part series
>> describing ftrace/trace-cmd on lwn
>> (https://old.lwn.net/Articles/365835/) a while ago.
>>
>> In terms of useability "trace-cmd" looked good to me and much more
>> powerful than the
>> current dmesg based printk style debugging.
>
> And then you learn about trace_printk() for putting custom one-off
> debug into the tracepoint stream and wonder why you didn't know
> about this years ago :P

Thanks for the pointers at the summit ...



-- 
Thanks,

Steve

Re: [linux-sunxi] [PATCH 07/15] dt-bindings: display: sun4i-drm: Add R40 HDMI pipeline

[Julian Calaby]

Hi Jernej,

On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec  wrote:
> Missing compatibles and descriptions needed to implement R40 HDMI
> pipeline are added.
>
> For mixers only compatibles are added.
>
> TCON description is expanded with R40 TV TCON compatibles. If the SoC
> has TCON TOP unit, phandle to that unit has to be specified. Additional
> clock has to be specified if SoC has TCON TOP and TCON is TV TCON.
>
> New compatible is added for DWC HDMI PHY, which has additional clock
> specified.

There's a bunch of A64 related stuff mixed in here, is the R40
compatible with the A64's parts? If so, you should probably mention
that in the commit log.

> Signed-off-by: Jernej Skrabec 
> ---
>  .../bindings/display/sunxi/sun4i-drm.txt | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index a099957ab62a..634276f713e8 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -111,8 +112,9 @@ Required properties:
>- resets: phandle to the reset controller driving the PHY
>- reset-names: must be "phy"
>
> -H3 HDMI PHY requires additional clock:
> +H3 and A64 HDMI PHY requires additional clocks:
>- pll-0: parent of phy clock
> +  - pll-1: second possible phy clock parent (A64 only)

Maybe split this into two:

H3 HDMI PHY ...
   - pll-0: ...

A64 HDMI PHY ...
   - pll-0: ...
   - pll-1: ...

At the moment a quick reading implies that H3 needs pll-1.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [linux-sunxi] [PATCH 07/15] dt-bindings: display: sun4i-drm: Add R40 HDMI pipeline

[Julian Calaby]

Hi Jernej,

On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec  wrote:
> Missing compatibles and descriptions needed to implement R40 HDMI
> pipeline are added.
>
> For mixers only compatibles are added.
>
> TCON description is expanded with R40 TV TCON compatibles. If the SoC
> has TCON TOP unit, phandle to that unit has to be specified. Additional
> clock has to be specified if SoC has TCON TOP and TCON is TV TCON.
>
> New compatible is added for DWC HDMI PHY, which has additional clock
> specified.

There's a bunch of A64 related stuff mixed in here, is the R40
compatible with the A64's parts? If so, you should probably mention
that in the commit log.

> Signed-off-by: Jernej Skrabec 
> ---
>  .../bindings/display/sunxi/sun4i-drm.txt | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index a099957ab62a..634276f713e8 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -111,8 +112,9 @@ Required properties:
>- resets: phandle to the reset controller driving the PHY
>- reset-names: must be "phy"
>
> -H3 HDMI PHY requires additional clock:
> +H3 and A64 HDMI PHY requires additional clocks:
>- pll-0: parent of phy clock
> +  - pll-1: second possible phy clock parent (A64 only)

Maybe split this into two:

H3 HDMI PHY ...
   - pll-0: ...

A64 HDMI PHY ...
   - pll-0: ...
   - pll-1: ...

At the moment a quick reading implies that H3 needs pll-1.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [RFC PATCH V2] scsi: ufs: Add specific callback for setting DMA mask

[Alim Akhtar]

Hi Subhash

On 05/17/2018 03:01 AM, Subhash Jadavani wrote:
> On 2018-05-15 21:31, Alim Akhtar wrote:
>> Ping !!!
>>
>> On Thu, Mar 8, 2018 at 4:33 PM, Alim Akhtar  
>> wrote:
>>> Currently DMA mask for UFS HCI is set by reading CAP register's
>>> [64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
>>> This works perfectly fine with DMA mask set as 64 in case there is no
>>> IOMMU attached to HCI.
>>> In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
>>> work as HCI has only 36bit addressing and SMMU has created mapping of
>>> 64 bit and as the device truncates the address, its mapping will not
>>> be found by iommu.
>>> To resolve such issues, let the variant driver sets its own DMA mask.
>>>
>>> Signed-off-by: Alim Akhtar 
>>> ---
>>>  drivers/scsi/ufs/ufshcd.c | 3 +++
>>>  drivers/scsi/ufs/ufshcd.h | 2 ++
>>>  2 files changed, 5 insertions(+)
>>>
>>> I am not sure if there are other ways available to handle such cases.
>>> The IOMMU I am talking about is arm-smmu and it DT binding does not
>>> give much idea about handling such cases.
>>> Have tested this patch with HCI controller with IOMMU attached.
>>>
>>> Changes Since V1:
>>>     - Fixed build issue as reported by Kbuild test robot.
>>>
>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> index a355d98..9a1374e 100644
>>> --- a/drivers/scsi/ufs/ufshcd.c
>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
>>>   */
>>>  static int ufshcd_set_dma_mask(struct ufs_hba *hba)
>>>  {
>>> +   if (hba->vops && hba->vops->set_dma_mask)
>>> +   return hba->vops->set_dma_mask(hba);
>>> +
>>>     if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
>>>     if (!dma_set_mask_and_coherent(hba->dev, 
>>> DMA_BIT_MASK(64)))
>>>     return 0;
>>> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
>>> index 1332e54..89c6dae 100644
>>> --- a/drivers/scsi/ufs/ufshcd.h
>>> +++ b/drivers/scsi/ufs/ufshcd.h
>>> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
>>>   * @resume: called during host controller PM callback
>>>   * @dbg_register_dump: used to dump controller debug information
>>>   * @phy_initialization: used to initialize phys
>>> + * @set_dma_mask: used to set variant specific DMA mask
>>>   */
>>>  struct ufs_hba_variant_ops {
>>>     const char *name;
>>> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
>>>     int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>>>     void    (*dbg_register_dump)(struct ufs_hba *hba);
>>>     int (*phy_initialization)(struct ufs_hba *);
>>> +   int (*set_dma_mask)(struct ufs_hba *hba);
>>>  };
>>>
>>>  /* clock gating state  */
>>> -- 
>>> 2.7.4
>>>
> 
> Looks reasonable to me, you may try posting non-RFC version.
> 
Thanks for review.
Will send a non-RFC version.

Regards,
Alim

Re: [RFC PATCH V2] scsi: ufs: Add specific callback for setting DMA mask

[Alim Akhtar]

Hi Subhash

On 05/17/2018 03:01 AM, Subhash Jadavani wrote:
> On 2018-05-15 21:31, Alim Akhtar wrote:
>> Ping !!!
>>
>> On Thu, Mar 8, 2018 at 4:33 PM, Alim Akhtar  
>> wrote:
>>> Currently DMA mask for UFS HCI is set by reading CAP register's
>>> [64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
>>> This works perfectly fine with DMA mask set as 64 in case there is no
>>> IOMMU attached to HCI.
>>> In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
>>> work as HCI has only 36bit addressing and SMMU has created mapping of
>>> 64 bit and as the device truncates the address, its mapping will not
>>> be found by iommu.
>>> To resolve such issues, let the variant driver sets its own DMA mask.
>>>
>>> Signed-off-by: Alim Akhtar 
>>> ---
>>>  drivers/scsi/ufs/ufshcd.c | 3 +++
>>>  drivers/scsi/ufs/ufshcd.h | 2 ++
>>>  2 files changed, 5 insertions(+)
>>>
>>> I am not sure if there are other ways available to handle such cases.
>>> The IOMMU I am talking about is arm-smmu and it DT binding does not
>>> give much idea about handling such cases.
>>> Have tested this patch with HCI controller with IOMMU attached.
>>>
>>> Changes Since V1:
>>>     - Fixed build issue as reported by Kbuild test robot.
>>>
>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> index a355d98..9a1374e 100644
>>> --- a/drivers/scsi/ufs/ufshcd.c
>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
>>>   */
>>>  static int ufshcd_set_dma_mask(struct ufs_hba *hba)
>>>  {
>>> +   if (hba->vops && hba->vops->set_dma_mask)
>>> +   return hba->vops->set_dma_mask(hba);
>>> +
>>>     if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
>>>     if (!dma_set_mask_and_coherent(hba->dev, 
>>> DMA_BIT_MASK(64)))
>>>     return 0;
>>> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
>>> index 1332e54..89c6dae 100644
>>> --- a/drivers/scsi/ufs/ufshcd.h
>>> +++ b/drivers/scsi/ufs/ufshcd.h
>>> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
>>>   * @resume: called during host controller PM callback
>>>   * @dbg_register_dump: used to dump controller debug information
>>>   * @phy_initialization: used to initialize phys
>>> + * @set_dma_mask: used to set variant specific DMA mask
>>>   */
>>>  struct ufs_hba_variant_ops {
>>>     const char *name;
>>> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
>>>     int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>>>     void    (*dbg_register_dump)(struct ufs_hba *hba);
>>>     int (*phy_initialization)(struct ufs_hba *);
>>> +   int (*set_dma_mask)(struct ufs_hba *hba);
>>>  };
>>>
>>>  /* clock gating state  */
>>> -- 
>>> 2.7.4
>>>
> 
> Looks reasonable to me, you may try posting non-RFC version.
> 
Thanks for review.
Will send a non-RFC version.

Regards,
Alim

Re: INFO: rcu detected stall in is_bpf_text_address

[Marcelo Ricardo Leitner]

On Sat, May 19, 2018 at 08:57:19AM -0700, Eric Dumazet wrote:
> SCTP experts, please take a look.

Ugh, same sctp footprint as in the other reports.

>
> >  _sctp_make_chunk+0x58/0x280 net/sctp/sm_make_chunk.c:1417
> >  sctp_make_control net/sctp/sm_make_chunk.c:1464 [inline]
> >  sctp_make_heartbeat+0x8f/0x430 net/sctp/sm_make_chunk.c:1177
> >  sctp_sf_heartbeat.isra.23+0x26/0x180 net/sctp/sm_statefuns.c:1005
> >  sctp_sf_sendbeat_8_3+0x38e/0x550 net/sctp/sm_statefuns.c:1049
> >  sctp_do_sm+0x1ab/0x7160 net/sctp/sm_sideeffect.c:1188
> >  sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
> >  call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
> >  expire_timers kernel/time/timer.c:1363 [inline]
> >  __run_timers+0x79e/0xc50 kernel/time/timer.c:1666
> >  run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692

Re: INFO: rcu detected stall in is_bpf_text_address

[Marcelo Ricardo Leitner]

On Sat, May 19, 2018 at 08:57:19AM -0700, Eric Dumazet wrote:
> SCTP experts, please take a look.

Ugh, same sctp footprint as in the other reports.

>
> >  _sctp_make_chunk+0x58/0x280 net/sctp/sm_make_chunk.c:1417
> >  sctp_make_control net/sctp/sm_make_chunk.c:1464 [inline]
> >  sctp_make_heartbeat+0x8f/0x430 net/sctp/sm_make_chunk.c:1177
> >  sctp_sf_heartbeat.isra.23+0x26/0x180 net/sctp/sm_statefuns.c:1005
> >  sctp_sf_sendbeat_8_3+0x38e/0x550 net/sctp/sm_statefuns.c:1049
> >  sctp_do_sm+0x1ab/0x7160 net/sctp/sm_sideeffect.c:1188
> >  sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
> >  call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
> >  expire_timers kernel/time/timer.c:1363 [inline]
> >  __run_timers+0x79e/0xc50 kernel/time/timer.c:1666
> >  run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692

Re: [PATCH net-next] net: dsa: b53: Extend platform data to include DSA ports

[Andrew Lunn]

On Sat, May 19, 2018 at 03:55:10PM -0700, Florian Fainelli wrote:
> Provide a means for !OF platforms to supply their DSA platform data
> configuration using the dsa_platform_data structure.

Hi Florian

It seems a bit odd adding the header file, but no code. Yes, this will
help simplify the merge dependencies for the ZII boards next cycle,
but can we have the actual code as well?

Thanks
Andrew
> 
> Signed-off-by: Florian Fainelli 
> ---
>  include/linux/platform_data/b53.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/platform_data/b53.h 
> b/include/linux/platform_data/b53.h
> index 69d279c0da96..8eaef2f2b691 100644
> --- a/include/linux/platform_data/b53.h
> +++ b/include/linux/platform_data/b53.h
> @@ -20,8 +20,12 @@
>  #define __B53_H
>  
>  #include 
> +#include 
>  
>  struct b53_platform_data {
> + /* Must be first such that dsa_register_switch() can access it */
> + struct dsa_chip_data cd;
> +
>   u32 chip_id;
>   u16 enabled_ports;
>  
> -- 
> 2.14.1
> 

Re: [PATCH net-next] net: dsa: b53: Extend platform data to include DSA ports

[Andrew Lunn]

On Sat, May 19, 2018 at 03:55:10PM -0700, Florian Fainelli wrote:
> Provide a means for !OF platforms to supply their DSA platform data
> configuration using the dsa_platform_data structure.

Hi Florian

It seems a bit odd adding the header file, but no code. Yes, this will
help simplify the merge dependencies for the ZII boards next cycle,
but can we have the actual code as well?

Thanks
Andrew
> 
> Signed-off-by: Florian Fainelli 
> ---
>  include/linux/platform_data/b53.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/platform_data/b53.h 
> b/include/linux/platform_data/b53.h
> index 69d279c0da96..8eaef2f2b691 100644
> --- a/include/linux/platform_data/b53.h
> +++ b/include/linux/platform_data/b53.h
> @@ -20,8 +20,12 @@
>  #define __B53_H
>  
>  #include 
> +#include 
>  
>  struct b53_platform_data {
> + /* Must be first such that dsa_register_switch() can access it */
> + struct dsa_chip_data cd;
> +
>   u32 chip_id;
>   u16 enabled_ports;
>  
> -- 
> 2.14.1
> 

[GIT PULL] ARM: SoC fixes

[Olof Johansson]

Hi Linus,

The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:

  Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-fixes

for you to fetch changes up to 709f490d5b594b9548577d2285ffeaad8a278b10:

  Merge tag 'tegra-for-4.17-fixes-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into fixes 
(2018-05-19 17:58:32 -0700)


ARM: SoC fixes for 4.17-rc

A handful of fixes. I've been queuing them up a bit too long so the list
is longer than it otherwise would have been spread out across a few -rcs.

In general, it's a scattering of fixes across several platforms, nothing
truly serious enough to point out.

There's a slightly larger batch of them for the Davinci platforms due
to work to bring them back to life after some time, so there's a handful
of regressions, some of them going back very far, others more recent.

There's also a few patches fixing DT on Renesas platforms since they
changed some bindings without remaining backwards compatible, splitting
up describing LVDS as a proper bridge instead of having it as part of the
display unit. We could push for them to be backwards compatible with old
device trees, but it's likely to regress eventually if nobody's actually
using said compatibility.


Adam Ford (3):
  ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues
  ARM: dts: logicpd-som-lv: Fix Audio Mute
  ARM: dts: logicpd-som-lv: Fix pinmux controller references

Bhadram Varka (1):
  arm64: tegra: Make BCM89610 PHY interrupt as active low

Clément Péron (1):
  ARM: dts: cygnus: fix irq type for arm global timer

Dan Carpenter (1):
  firmware: arm_scmi: Use after free in scmi_create_protocol_device()

Dmitry Osipenko (1):
  ARM: dts: tegra20: Revert "Fix ULPI regression on Tegra20"

Etienne Carriere (1):
  tee: check shm references are consistent in offset/size

Fabio Estevam (1):
  ARM: dts: imx7s: Pass the 'fsl,sec-era' property

Graeme Smecher (1):
  ARM: dts: correct missing "compatible" entry for ti81xx SoCs

Jann Horn (1):
  tee: shm: fix use-after-free via temporarily dropped reference

Janusz Krzysztofik (1):
  ARM: OMAP1: ams-delta: fix deferred_fiq handler

Laurent Pinchart (3):
  ARM: dts: r8a7790: Convert to new LVDS DT bindings
  ARM: dts: r8a7791: Convert to new LVDS DT bindings
  ARM: dts: r8a7793: Convert to new LVDS DT bindings

Marek Szyprowski (1):
  arm64: dts: exynos: Fix interrupt type for I2S1 device on Exynos5433

Masahiro Yamada (3):
  arm64: dts: uniphier: fix input delay value for legacy mode of eMMC
  reset: uniphier: fix USB clock line for LD20
  arm64: dts: uniphier: stabilize ethernet of LD20 reference board

Maxime Chevallier (2):
  ARM64: dts: marvell: armada-cp110: Add clocks for the xmdio node
  ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node

Nikita Yushchenko (1):
  ARM: dts: imx51-zii-rdu1: fix touchscreen bindings

Olof Johansson (13):
  Merge tag 'uniphier-fixes-v4.17' of 
git://git.kernel.org/.../masahiroy/linux-uniphier into fixes
  Merge tag 'renesas-fixes-for-v4.17' of 
https://git.kernel.org/.../horms/renesas into fixes
  Merge tag 'davinci-fixes-for-v4.17' of 
git://git.kernel.org/.../nsekhar/linux-davinci into fixes
  Merge tag 'tegra-for-4.17-fixes' of git://git.kernel.org/.../tegra/linux 
into fixes
  Merge tag 'tee-drv-fixes-for-4.17' of 
git://git.linaro.org/people/jens.wiklander/linux-tee into fixes
  Merge tag 'arm-soc/for-4.17/devicetree-fixes' of 
https://github.com/Broadcom/stblinux into fixes
  Merge tag 'omap-for-v17/fixes-rc4' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes
  Merge tag 'scmi-fixes-4.17' of 
git://git.kernel.org/.../sudeep.holla/linux into fixes
  Merge tag 'imx-fixes-4.17' of git://git.kernel.org/.../shawnguo/linux 
into fixes
  Merge tag 'mvebu-fixes-4.17-1' of git://git.infradead.org/linux-mvebu 
into fixes
  Merge tag 'reset-fixes-for-4.17' of git://git.pengutronix.de/pza/linux 
into fixes
  Merge tag 'davinci-fixes-for-v4.17-part-2' of 
git://git.kernel.org/.../nsekhar/linux-davinci into fixes
  Merge tag 'tegra-for-4.17-fixes-2' of 
git://git.kernel.org/.../tegra/linux into fixes

Russell King (1):
  ARM: keystone: fix platform_domain_notifier array overrun

Sekhar Nori (11):
  ARM: dts: da850: get rid of skeleton.dtsi
  ARM: dts: da850-lcdk: add unit name for memory node
  ARM: dts: da850: fix W=1 warnings with pinmux node
  ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD
  ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD
  ARM: davinci: board-omapl138-hawk: fix GPIO numbers for MMC/SD lookup
  ARM: davinci: board-dm355-evm: fix 

[GIT PULL] ARM: SoC fixes

[Olof Johansson]

Hi Linus,

The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:

  Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-fixes

for you to fetch changes up to 709f490d5b594b9548577d2285ffeaad8a278b10:

  Merge tag 'tegra-for-4.17-fixes-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into fixes 
(2018-05-19 17:58:32 -0700)


ARM: SoC fixes for 4.17-rc

A handful of fixes. I've been queuing them up a bit too long so the list
is longer than it otherwise would have been spread out across a few -rcs.

In general, it's a scattering of fixes across several platforms, nothing
truly serious enough to point out.

There's a slightly larger batch of them for the Davinci platforms due
to work to bring them back to life after some time, so there's a handful
of regressions, some of them going back very far, others more recent.

There's also a few patches fixing DT on Renesas platforms since they
changed some bindings without remaining backwards compatible, splitting
up describing LVDS as a proper bridge instead of having it as part of the
display unit. We could push for them to be backwards compatible with old
device trees, but it's likely to regress eventually if nobody's actually
using said compatibility.


Adam Ford (3):
  ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues
  ARM: dts: logicpd-som-lv: Fix Audio Mute
  ARM: dts: logicpd-som-lv: Fix pinmux controller references

Bhadram Varka (1):
  arm64: tegra: Make BCM89610 PHY interrupt as active low

Clément Péron (1):
  ARM: dts: cygnus: fix irq type for arm global timer

Dan Carpenter (1):
  firmware: arm_scmi: Use after free in scmi_create_protocol_device()

Dmitry Osipenko (1):
  ARM: dts: tegra20: Revert "Fix ULPI regression on Tegra20"

Etienne Carriere (1):
  tee: check shm references are consistent in offset/size

Fabio Estevam (1):
  ARM: dts: imx7s: Pass the 'fsl,sec-era' property

Graeme Smecher (1):
  ARM: dts: correct missing "compatible" entry for ti81xx SoCs

Jann Horn (1):
  tee: shm: fix use-after-free via temporarily dropped reference

Janusz Krzysztofik (1):
  ARM: OMAP1: ams-delta: fix deferred_fiq handler

Laurent Pinchart (3):
  ARM: dts: r8a7790: Convert to new LVDS DT bindings
  ARM: dts: r8a7791: Convert to new LVDS DT bindings
  ARM: dts: r8a7793: Convert to new LVDS DT bindings

Marek Szyprowski (1):
  arm64: dts: exynos: Fix interrupt type for I2S1 device on Exynos5433

Masahiro Yamada (3):
  arm64: dts: uniphier: fix input delay value for legacy mode of eMMC
  reset: uniphier: fix USB clock line for LD20
  arm64: dts: uniphier: stabilize ethernet of LD20 reference board

Maxime Chevallier (2):
  ARM64: dts: marvell: armada-cp110: Add clocks for the xmdio node
  ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node

Nikita Yushchenko (1):
  ARM: dts: imx51-zii-rdu1: fix touchscreen bindings

Olof Johansson (13):
  Merge tag 'uniphier-fixes-v4.17' of 
git://git.kernel.org/.../masahiroy/linux-uniphier into fixes
  Merge tag 'renesas-fixes-for-v4.17' of 
https://git.kernel.org/.../horms/renesas into fixes
  Merge tag 'davinci-fixes-for-v4.17' of 
git://git.kernel.org/.../nsekhar/linux-davinci into fixes
  Merge tag 'tegra-for-4.17-fixes' of git://git.kernel.org/.../tegra/linux 
into fixes
  Merge tag 'tee-drv-fixes-for-4.17' of 
git://git.linaro.org/people/jens.wiklander/linux-tee into fixes
  Merge tag 'arm-soc/for-4.17/devicetree-fixes' of 
https://github.com/Broadcom/stblinux into fixes
  Merge tag 'omap-for-v17/fixes-rc4' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes
  Merge tag 'scmi-fixes-4.17' of 
git://git.kernel.org/.../sudeep.holla/linux into fixes
  Merge tag 'imx-fixes-4.17' of git://git.kernel.org/.../shawnguo/linux 
into fixes
  Merge tag 'mvebu-fixes-4.17-1' of git://git.infradead.org/linux-mvebu 
into fixes
  Merge tag 'reset-fixes-for-4.17' of git://git.pengutronix.de/pza/linux 
into fixes
  Merge tag 'davinci-fixes-for-v4.17-part-2' of 
git://git.kernel.org/.../nsekhar/linux-davinci into fixes
  Merge tag 'tegra-for-4.17-fixes-2' of 
git://git.kernel.org/.../tegra/linux into fixes

Russell King (1):
  ARM: keystone: fix platform_domain_notifier array overrun

Sekhar Nori (11):
  ARM: dts: da850: get rid of skeleton.dtsi
  ARM: dts: da850-lcdk: add unit name for memory node
  ARM: dts: da850: fix W=1 warnings with pinmux node
  ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD
  ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD
  ARM: davinci: board-omapl138-hawk: fix GPIO numbers for MMC/SD lookup
  ARM: davinci: board-dm355-evm: fix 

Re: Tasks RCU vs Preempt RCU

[Joel Fernandes]

On Sat, May 19, 2018 at 05:49:38PM -0700, Paul E. McKenney wrote:
[...]
> > > And the problem with wrapping them with rcu_read_{lock,unlock} is that
> > > there would be a point before the trampoline executed rcu_read_lock()
> > > but while it was on the trampoline.  Nothing good comes from this.  ;-)
> > 
> > Yes, I see what you're saying. The data being protected and freed in this
> > case is the code so relying on it to do the rcu_read_lock seems infeasible.
> > Conceptually atleast, I feel this can be fixed by cleverly implementing
> > trampolines such that the rcu_read_lock isn't done during the trampoline
> > execution. But I am not very experienced with how the trampolines work to 
> > say
> > definitely whether it is or isn't possible or worth it. But atleast I felt 
> > it
> > was a worthwhile food for thought ;)
> 
> I suggested to Steven that the rcu_read_lock() and rcu_read_unlock() might
> be outside of the trampoline, but this turned out to be infeasible.  Not
> that I remember why!  ;-)
> 
> > I actually want to trace out the trampoline executing as it pertains to RCU,
> > with your latest rcu/dev.. I think it will be fun :)
> 
> Cool!
> 
> In addition, if you are interested, it might be worth looking for fields
> in rcu_dynticks, rcu_data, rcu_node, and rcu_state that are no longer
> actually used.  It might also be worth looking for RCU macros that are
> no longer used.

Yes, definitely interested. Will keep an eye out for such fields and macros.

thanks!

 - Joel

Re: Tasks RCU vs Preempt RCU

[Joel Fernandes]

On Sat, May 19, 2018 at 05:49:38PM -0700, Paul E. McKenney wrote:
[...]
> > > And the problem with wrapping them with rcu_read_{lock,unlock} is that
> > > there would be a point before the trampoline executed rcu_read_lock()
> > > but while it was on the trampoline.  Nothing good comes from this.  ;-)
> > 
> > Yes, I see what you're saying. The data being protected and freed in this
> > case is the code so relying on it to do the rcu_read_lock seems infeasible.
> > Conceptually atleast, I feel this can be fixed by cleverly implementing
> > trampolines such that the rcu_read_lock isn't done during the trampoline
> > execution. But I am not very experienced with how the trampolines work to 
> > say
> > definitely whether it is or isn't possible or worth it. But atleast I felt 
> > it
> > was a worthwhile food for thought ;)
> 
> I suggested to Steven that the rcu_read_lock() and rcu_read_unlock() might
> be outside of the trampoline, but this turned out to be infeasible.  Not
> that I remember why!  ;-)
> 
> > I actually want to trace out the trampoline executing as it pertains to RCU,
> > with your latest rcu/dev.. I think it will be fun :)
> 
> Cool!
> 
> In addition, if you are interested, it might be worth looking for fields
> in rcu_dynticks, rcu_data, rcu_node, and rcu_state that are no longer
> actually used.  It might also be worth looking for RCU macros that are
> no longer used.

Yes, definitely interested. Will keep an eye out for such fields and macros.

thanks!

 - Joel

Re: Tasks RCU vs Preempt RCU

[Paul E. McKenney]

On Sat, May 19, 2018 at 03:59:05PM -0700, Joel Fernandes wrote:
> On Fri, May 18, 2018 at 07:29:18PM -0700, Paul E. McKenney wrote:
> > On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote:
> > > Hi,
> > > 
> > > I was thinking about tasks-RCU and why its needed. Since preempt-RCU 
> > > allows
> > > tasks to be preempted in read-sections, can we not just reuse that 
> > > mechanism
> > > for the trampolines since we track all preempted tasks so we would wait on
> > > all tasks preempted within a trampoline?
> > > 
> > > I am trying to understand what will _not_ work if we did that.. I'm 
> > > guessing
> > > the answer is that that would mean the trampoline has to be wrapped with
> > > rcu_read_{lock,unlock} which may add some overhead, but please let me know
> > > if I'm missing something else..
> > > 
> > > The advantage I guess is possible elimination of an RCU variant, and also
> > > possibly eliminating the tasks RCU thread that monitors.. Anyway I was
> > > thinking more in terms of the effort of reduction of the RCU flavors etc 
> > > and
> > > reducing complexity ideas.
> > 
> > The problem is that if they are preempted while executing in a trampoline,
> > RCU-preempt doesn't queue them nor does it wait on them.
> 
> Not if they are wrapped with rcu_read_lock and rcu_read_unlock? From what I
> can see, you are preparing a list of blocked tasks that would keep the grace 
> period
> from finishing in rcu_preempt_ctxt_queue?

But being on the ->blkd_tasks list doesn't necessarily block the current
grace period.  Only those tasks on that list that are also referenced
by ->gp_tasks (or that follow some task referenced by ->gp_tasks)
will block the current grace period.  This is be design -- otherwise,
an endless stream of tasks blocking in their RCU read-side critical
sections could prevent the current grace period from ever ending.

> > And the problem with wrapping them with rcu_read_{lock,unlock} is that
> > there would be a point before the trampoline executed rcu_read_lock()
> > but while it was on the trampoline.  Nothing good comes from this.  ;-)
> 
> Yes, I see what you're saying. The data being protected and freed in this
> case is the code so relying on it to do the rcu_read_lock seems infeasible.
> Conceptually atleast, I feel this can be fixed by cleverly implementing
> trampolines such that the rcu_read_lock isn't done during the trampoline
> execution. But I am not very experienced with how the trampolines work to say
> definitely whether it is or isn't possible or worth it. But atleast I felt it
> was a worthwhile food for thought ;)

I suggested to Steven that the rcu_read_lock() and rcu_read_unlock() might
be outside of the trampoline, but this turned out to be infeasible.  Not
that I remember why!  ;-)

> I actually want to trace out the trampoline executing as it pertains to RCU,
> with your latest rcu/dev.. I think it will be fun :)

Cool!

In addition, if you are interested, it might be worth looking for fields
in rcu_dynticks, rcu_data, rcu_node, and rcu_state that are no longer
actually used.  It might also be worth looking for RCU macros that are
no longer used.

I found a few by accident, so there are probably more...

Thanx, Paul

Re: Tasks RCU vs Preempt RCU

[Paul E. McKenney]

On Sat, May 19, 2018 at 03:59:05PM -0700, Joel Fernandes wrote:
> On Fri, May 18, 2018 at 07:29:18PM -0700, Paul E. McKenney wrote:
> > On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote:
> > > Hi,
> > > 
> > > I was thinking about tasks-RCU and why its needed. Since preempt-RCU 
> > > allows
> > > tasks to be preempted in read-sections, can we not just reuse that 
> > > mechanism
> > > for the trampolines since we track all preempted tasks so we would wait on
> > > all tasks preempted within a trampoline?
> > > 
> > > I am trying to understand what will _not_ work if we did that.. I'm 
> > > guessing
> > > the answer is that that would mean the trampoline has to be wrapped with
> > > rcu_read_{lock,unlock} which may add some overhead, but please let me know
> > > if I'm missing something else..
> > > 
> > > The advantage I guess is possible elimination of an RCU variant, and also
> > > possibly eliminating the tasks RCU thread that monitors.. Anyway I was
> > > thinking more in terms of the effort of reduction of the RCU flavors etc 
> > > and
> > > reducing complexity ideas.
> > 
> > The problem is that if they are preempted while executing in a trampoline,
> > RCU-preempt doesn't queue them nor does it wait on them.
> 
> Not if they are wrapped with rcu_read_lock and rcu_read_unlock? From what I
> can see, you are preparing a list of blocked tasks that would keep the grace 
> period
> from finishing in rcu_preempt_ctxt_queue?

But being on the ->blkd_tasks list doesn't necessarily block the current
grace period.  Only those tasks on that list that are also referenced
by ->gp_tasks (or that follow some task referenced by ->gp_tasks)
will block the current grace period.  This is be design -- otherwise,
an endless stream of tasks blocking in their RCU read-side critical
sections could prevent the current grace period from ever ending.

> > And the problem with wrapping them with rcu_read_{lock,unlock} is that
> > there would be a point before the trampoline executed rcu_read_lock()
> > but while it was on the trampoline.  Nothing good comes from this.  ;-)
> 
> Yes, I see what you're saying. The data being protected and freed in this
> case is the code so relying on it to do the rcu_read_lock seems infeasible.
> Conceptually atleast, I feel this can be fixed by cleverly implementing
> trampolines such that the rcu_read_lock isn't done during the trampoline
> execution. But I am not very experienced with how the trampolines work to say
> definitely whether it is or isn't possible or worth it. But atleast I felt it
> was a worthwhile food for thought ;)

I suggested to Steven that the rcu_read_lock() and rcu_read_unlock() might
be outside of the trampoline, but this turned out to be infeasible.  Not
that I remember why!  ;-)

> I actually want to trace out the trampoline executing as it pertains to RCU,
> with your latest rcu/dev.. I think it will be fun :)

Cool!

In addition, if you are interested, it might be worth looking for fields
in rcu_dynticks, rcu_data, rcu_node, and rcu_state that are no longer
actually used.  It might also be worth looking for RCU macros that are
no longer used.

I found a few by accident, so there are probably more...

Thanx, Paul

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

[Paul E. McKenney]

On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote:
> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney
>  wrote:
> > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote:
> >> Function is going to be used in transport over RDMA module
> >> in subsequent patches.
> >>
> >> Function returns next element in round-robin fashion,
> >> i.e. head will be skipped.  NULL will be returned if list
> >> is observed as empty.
> >>
> >> Signed-off-by: Roman Pen 
> >> Cc: Paul E. McKenney 
> >> Cc: linux-kernel@vger.kernel.org
> >> ---
> >>  include/linux/rculist.h | 19 +++
> >>  1 file changed, 19 insertions(+)
> >>
> >> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> >> index 127f534fec94..b0840d5ab25a 100644
> >> --- a/include/linux/rculist.h
> >> +++ b/include/linux/rculist.h
> >> @@ -339,6 +339,25 @@ static inline void list_splice_tail_init_rcu(struct 
> >> list_head *list,
> >>  })
> >>
> >>  /**
> >> + * list_next_or_null_rr_rcu - get next list element in round-robin 
> >> fashion.
> >> + * @head:the head for the list.
> >> + * @ptr:the list head to take the next element from.
> >> + * @type:   the type of the struct this is embedded in.
> >> + * @memb:   the name of the list_head within the struct.
> >> + *
> >> + * Next element returned in round-robin fashion, i.e. head will be 
> >> skipped,
> >> + * but if list is observed as empty, NULL will be returned.
> >> + *
> >> + * This primitive may safely run concurrently with the _rcu list-mutation
> >> + * primitives such as list_add_rcu() as long as it's guarded by 
> >> rcu_read_lock().
> >
> > Of course, all the set of list_next_or_null_rr_rcu() invocations that
> > are round-robining a given list must all be under the same RCU read-side
> > critical section.  For example, the following will break badly:
> >
> > struct foo *take_rr_step(struct list_head *head, struct foo *ptr)
> > {
> > struct foo *ret;
> >
> > rcu_read_lock();
> > ret = list_next_or_null_rr_rcu(head, ptr, struct foo, 
> > foolist);
> > rcu_read_unlock();  /* BUG */
> > return ret;
> > }
> >
> > You need a big fat comment stating this, at the very least.  The resulting
> > bug can be very hard to trigger and even harder to debug.
> >
> > And yes, I know that the same restriction applies to list_next_rcu()
> > and friends.  The difference is that if you try to invoke those in an
> > infinite loop, you will be rapped on the knuckles as soon as you hit
> > the list header.  Without that knuckle-rapping, RCU CPU stall warnings
> > might tempt people to do something broken like take_rr_step() above.
> 
> Hi Paul,
> 
> I need -rr behaviour for doing IO load-balancing when I choose next RDMA
> connection from the list in order to send a request, i.e. my code is
> something like the following:
> 
> static struct conn *get_and_set_next_conn(void)
> {
> struct conn *conn;
> 
> conn = rcu_dereferece(rcu_conn);
> if (unlikely(!conn))
> return conn;

Wait.  Don't you need to restart from the beginning of the list in
this case?  Or does the list never have anything added to it and is
rcu_conn initially the first element in the list?

> conn = list_next_or_null_rr_rcu(_list,
> >entry,
> typeof(*conn),
> entry);
> rcu_assign_pointer(rcu_conn, conn);

Linus is correct to doubt this code.  You assign a pointer to the current
element to rcu_conn, which is presumably a per-CPU or global variable.
So far, so good ...

> return conn;
> }
> 
> rcu_read_lock();
> conn = get_and_set_next_conn();
> if (unlikely(!conn)) {
> /* ... */
> }
> err = rdma_io(conn, request);
> rcu_read_unlock();

... except that some other CPU might well remove the entry referenced by
rcu_conn at this point.  It would have to wait for a grace period (e.g.,
synchronize_rcu()), but the current CPU has exited its RCU read-side
critical section, and therefore is not blocking the grace period.
Therefore, by the time get_and_set_next_conn() picks up rcu_conn, it
might well be referencing the freelist, or, even worse, some other type
of structure.

What is your code doing to prevent this from happening?  (There are ways,
but I want to know what you were doing in this case.)

> i.e. usage of the @next pointer is under an RCU critical section.
> 
> > Is it possible to instead do some sort of list_for_each_entry_rcu()-like
> > macro that makes it more obvious that the whole thing need to be under
> > a single RCU read-side critical section?  Such a macro 

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

[Paul E. McKenney]

On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote:
> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney
>  wrote:
> > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote:
> >> Function is going to be used in transport over RDMA module
> >> in subsequent patches.
> >>
> >> Function returns next element in round-robin fashion,
> >> i.e. head will be skipped.  NULL will be returned if list
> >> is observed as empty.
> >>
> >> Signed-off-by: Roman Pen 
> >> Cc: Paul E. McKenney 
> >> Cc: linux-kernel@vger.kernel.org
> >> ---
> >>  include/linux/rculist.h | 19 +++
> >>  1 file changed, 19 insertions(+)
> >>
> >> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> >> index 127f534fec94..b0840d5ab25a 100644
> >> --- a/include/linux/rculist.h
> >> +++ b/include/linux/rculist.h
> >> @@ -339,6 +339,25 @@ static inline void list_splice_tail_init_rcu(struct 
> >> list_head *list,
> >>  })
> >>
> >>  /**
> >> + * list_next_or_null_rr_rcu - get next list element in round-robin 
> >> fashion.
> >> + * @head:the head for the list.
> >> + * @ptr:the list head to take the next element from.
> >> + * @type:   the type of the struct this is embedded in.
> >> + * @memb:   the name of the list_head within the struct.
> >> + *
> >> + * Next element returned in round-robin fashion, i.e. head will be 
> >> skipped,
> >> + * but if list is observed as empty, NULL will be returned.
> >> + *
> >> + * This primitive may safely run concurrently with the _rcu list-mutation
> >> + * primitives such as list_add_rcu() as long as it's guarded by 
> >> rcu_read_lock().
> >
> > Of course, all the set of list_next_or_null_rr_rcu() invocations that
> > are round-robining a given list must all be under the same RCU read-side
> > critical section.  For example, the following will break badly:
> >
> > struct foo *take_rr_step(struct list_head *head, struct foo *ptr)
> > {
> > struct foo *ret;
> >
> > rcu_read_lock();
> > ret = list_next_or_null_rr_rcu(head, ptr, struct foo, 
> > foolist);
> > rcu_read_unlock();  /* BUG */
> > return ret;
> > }
> >
> > You need a big fat comment stating this, at the very least.  The resulting
> > bug can be very hard to trigger and even harder to debug.
> >
> > And yes, I know that the same restriction applies to list_next_rcu()
> > and friends.  The difference is that if you try to invoke those in an
> > infinite loop, you will be rapped on the knuckles as soon as you hit
> > the list header.  Without that knuckle-rapping, RCU CPU stall warnings
> > might tempt people to do something broken like take_rr_step() above.
> 
> Hi Paul,
> 
> I need -rr behaviour for doing IO load-balancing when I choose next RDMA
> connection from the list in order to send a request, i.e. my code is
> something like the following:
> 
> static struct conn *get_and_set_next_conn(void)
> {
> struct conn *conn;
> 
> conn = rcu_dereferece(rcu_conn);
> if (unlikely(!conn))
> return conn;

Wait.  Don't you need to restart from the beginning of the list in
this case?  Or does the list never have anything added to it and is
rcu_conn initially the first element in the list?

> conn = list_next_or_null_rr_rcu(_list,
> >entry,
> typeof(*conn),
> entry);
> rcu_assign_pointer(rcu_conn, conn);

Linus is correct to doubt this code.  You assign a pointer to the current
element to rcu_conn, which is presumably a per-CPU or global variable.
So far, so good ...

> return conn;
> }
> 
> rcu_read_lock();
> conn = get_and_set_next_conn();
> if (unlikely(!conn)) {
> /* ... */
> }
> err = rdma_io(conn, request);
> rcu_read_unlock();

... except that some other CPU might well remove the entry referenced by
rcu_conn at this point.  It would have to wait for a grace period (e.g.,
synchronize_rcu()), but the current CPU has exited its RCU read-side
critical section, and therefore is not blocking the grace period.
Therefore, by the time get_and_set_next_conn() picks up rcu_conn, it
might well be referencing the freelist, or, even worse, some other type
of structure.

What is your code doing to prevent this from happening?  (There are ways,
but I want to know what you were doing in this case.)

> i.e. usage of the @next pointer is under an RCU critical section.
> 
> > Is it possible to instead do some sort of list_for_each_entry_rcu()-like
> > macro that makes it more obvious that the whole thing need to be under
> > a single RCU read-side critical section?  Such a macro would of course be
> > an infinite loop if the list never went empty, so presumably 

[RHEL-8] arm64: add missing early clobber in atomic64_dec_if_positive()

[Mark Salter]

When running a kernel compiled with gcc8 on a machine using LSE, I
get:

 Unable to handle kernel paging request at virtual address 112221
 Mem abort info:
   ESR = 0x9621
   Exception class = DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
 Data abort info:
   ISV = 0, ISS = 0x0021
   CM = 0, WnR = 0
 [00112221] address between user and kernel address ranges
 Internal error: Oops: 9621 [#1] SMP
 ...
 pstate: 2049 (nzCv daif +PAN -UAO)
 pc : test_atomic64+0x1360/0x155c
 lr : 0x
 sp : 0bc6fd60
 x29: 0bc6fd60 x28: 
 x27:  x26: 08f04460
 x25: 08de0584 x24: 08e91060
 x23: aaa31337c001d00e x22: 999202269ddfadeb
 x21: aaa31337c001d00c x20: bbb42448e223f22f
 x19: aaa31337c001d00d x18: 0010
 x17: 0222 x16: 10e0
 x15:  x14: 09233c08
 x13: 89925a8f x12: 09925a97
 x11: 0927f000 x10: 0bc6fac0
 x9 : ffd0 x8 : 0853fdf8
 x7 : deadbeef x6 : 0bc6fda0
 x5 : aaa31337c001d00d x4 : deadbeefdeafcafe
 x3 : aaa31337c001d00d x2 : aaa31337c001d00e
 x1 :  x0 : 2221
 Process swapper/0 (pid: 1, stack limit = 0x8209f908)
 Call trace:
  test_atomic64+0x1360/0x155c
  test_atomics_init+0x10/0x28
  do_one_initcall+0x134/0x160
  kernel_init_freeable+0x18c/0x21c
  kernel_init+0x18/0x108
  ret_from_fork+0x10/0x1c
 Code: f90023e1 f940001e f10007c0 54ab (c8fefc00)
 ---[ end trace 29569e7320c6e926 ]---

The fault happens at the casal insn of inlined atomic64_dec_if_positive().
The inline asm code in that function has:

"1: ldr x30, %[v]\n"
"   subs%[ret], x30, #1\n"
"   b.lt2f\n"
"   casal   x30, %[ret], %[v]\n"
"   sub x30, x30, #1\n"
"   sub x30, x30, %[ret]\n"
"   cbnzx30, 1b\n"
"2:")
: [ret] "+r" (x0), [v] "+Q" (v->counter)

gcc8 used register x0 for both [ret] and [v] and the subs was
clobbering [v] before it was used for casal. Gcc is free to do
this because [ret] lacks an early clobber modifier. So add one
to tell gcc a separate register is needed for [v].

Signed-off-by: Mark Salter 
---
 arch/arm64/include/asm/atomic_lse.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/atomic_lse.h 
b/arch/arm64/include/asm/atomic_lse.h
index 9ef0797380cb..99fa69c9c3cf 100644
--- a/arch/arm64/include/asm/atomic_lse.h
+++ b/arch/arm64/include/asm/atomic_lse.h
@@ -435,7 +435,7 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
"   sub x30, x30, %[ret]\n"
"   cbnzx30, 1b\n"
"2:")
-   : [ret] "+r" (x0), [v] "+Q" (v->counter)
+   : [ret] "+" (x0), [v] "+Q" (v->counter)
:
: __LL_SC_CLOBBERS, "cc", "memory");
 
-- 
2.17.0

[RHEL-8] arm64: add missing early clobber in atomic64_dec_if_positive()

[Mark Salter]

When running a kernel compiled with gcc8 on a machine using LSE, I
get:

 Unable to handle kernel paging request at virtual address 112221
 Mem abort info:
   ESR = 0x9621
   Exception class = DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
 Data abort info:
   ISV = 0, ISS = 0x0021
   CM = 0, WnR = 0
 [00112221] address between user and kernel address ranges
 Internal error: Oops: 9621 [#1] SMP
 ...
 pstate: 2049 (nzCv daif +PAN -UAO)
 pc : test_atomic64+0x1360/0x155c
 lr : 0x
 sp : 0bc6fd60
 x29: 0bc6fd60 x28: 
 x27:  x26: 08f04460
 x25: 08de0584 x24: 08e91060
 x23: aaa31337c001d00e x22: 999202269ddfadeb
 x21: aaa31337c001d00c x20: bbb42448e223f22f
 x19: aaa31337c001d00d x18: 0010
 x17: 0222 x16: 10e0
 x15:  x14: 09233c08
 x13: 89925a8f x12: 09925a97
 x11: 0927f000 x10: 0bc6fac0
 x9 : ffd0 x8 : 0853fdf8
 x7 : deadbeef x6 : 0bc6fda0
 x5 : aaa31337c001d00d x4 : deadbeefdeafcafe
 x3 : aaa31337c001d00d x2 : aaa31337c001d00e
 x1 :  x0 : 2221
 Process swapper/0 (pid: 1, stack limit = 0x8209f908)
 Call trace:
  test_atomic64+0x1360/0x155c
  test_atomics_init+0x10/0x28
  do_one_initcall+0x134/0x160
  kernel_init_freeable+0x18c/0x21c
  kernel_init+0x18/0x108
  ret_from_fork+0x10/0x1c
 Code: f90023e1 f940001e f10007c0 54ab (c8fefc00)
 ---[ end trace 29569e7320c6e926 ]---

The fault happens at the casal insn of inlined atomic64_dec_if_positive().
The inline asm code in that function has:

"1: ldr x30, %[v]\n"
"   subs%[ret], x30, #1\n"
"   b.lt2f\n"
"   casal   x30, %[ret], %[v]\n"
"   sub x30, x30, #1\n"
"   sub x30, x30, %[ret]\n"
"   cbnzx30, 1b\n"
"2:")
: [ret] "+r" (x0), [v] "+Q" (v->counter)

gcc8 used register x0 for both [ret] and [v] and the subs was
clobbering [v] before it was used for casal. Gcc is free to do
this because [ret] lacks an early clobber modifier. So add one
to tell gcc a separate register is needed for [v].

Signed-off-by: Mark Salter 
---
 arch/arm64/include/asm/atomic_lse.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/atomic_lse.h 
b/arch/arm64/include/asm/atomic_lse.h
index 9ef0797380cb..99fa69c9c3cf 100644
--- a/arch/arm64/include/asm/atomic_lse.h
+++ b/arch/arm64/include/asm/atomic_lse.h
@@ -435,7 +435,7 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
"   sub x30, x30, %[ret]\n"
"   cbnzx30, 1b\n"
"2:")
-   : [ret] "+r" (x0), [v] "+Q" (v->counter)
+   : [ret] "+" (x0), [v] "+Q" (v->counter)
:
: __LL_SC_CLOBBERS, "cc", "memory");
 
-- 
2.17.0

Re: [PATCHv2][SMB3] Add kernel trace support

[Dave Chinner]

On Fri, May 18, 2018 at 01:43:14PM -0700, Steve French wrote:
> On Fri, May 18, 2018 at 11:46 AM, Ralph Böhme  wrote:
> > On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical 
> > wrote:
> >> Patch updated with additional tracepoint locations and some formatting
> >> improvements. There are some obvious additional tracepoints that could
> >> be added, but this should be a reasonable group to start with.
> >>
> >> From edc02d6f9dc24963d510c7ef59067428d3b082d3 Mon Sep 17 00:00:00 2001
> >> From: Steve French 
> >> Date: Thu, 17 May 2018 21:16:55 -0500
> >> Subject: [PATCH] smb3: Add ftrace tracepoints for improved SMB3 debugging
> >>
> >> Although dmesg logs and wireshark network traces can be
> >> helpful, being able to dynamically enable/disable tracepoints
> >> (in this case via the kernel ftrace mechanism) can also be
> >> helpful in more quickly debugging problems, and more
> >> selectively tracing the events related to the bug report.
> >>
> >> This patch adds 12 ftrace tracepoints to cifs.ko for SMB3 events
> >> in some obvious locations.  Subsequent patches will add more
> >> as needed.
> >>
> >> Example use:
> >>trace-cmd record -e cifs
> >>
> >>trace-cmd show
> >
> > pardon my ignorance, but are these tracepoints usable with other tracing
> > frameworks like Systemtap?
> >
> > Last time I checked, Systemtap looked like *the* tool.

Systemtap is great when you have a need for custom tracing. But for
day-to-day kernel development, tracepoints are far more useful
because they are always there and can cover all the common
situations that you need to trace.

And when it comes to debugging a one-off user problem when the user
knows nothing about systemtap?  Nothing beats asking the user
to run a trace on built-in tracepoints, reproduce the problem and
send the trace report back as per the above example.

> > Is there a generic trace
> > point infrastructure that tracing tools can consume, so we're not tied to
> > ftrace?
> 
> At the kernel filesystem/mm summit a few recommended using ftrace
> (trace-cmd).  Don't know what
> the thinking is about this vs. systemtap these days.  There was a nice
> three part series
> describing ftrace/trace-cmd on lwn
> (https://old.lwn.net/Articles/365835/) a while ago.
> 
> In terms of useability "trace-cmd" looked good to me and much more
> powerful than the
> current dmesg based printk style debugging.

And then you learn about trace_printk() for putting custom one-off
debug into the tracepoint stream and wonder why you didn't know
about this years ago :P

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCHv2][SMB3] Add kernel trace support

[Dave Chinner]

On Fri, May 18, 2018 at 01:43:14PM -0700, Steve French wrote:
> On Fri, May 18, 2018 at 11:46 AM, Ralph Böhme  wrote:
> > On Thu, May 17, 2018 at 09:36:36PM -0500, Steve French via samba-technical 
> > wrote:
> >> Patch updated with additional tracepoint locations and some formatting
> >> improvements. There are some obvious additional tracepoints that could
> >> be added, but this should be a reasonable group to start with.
> >>
> >> From edc02d6f9dc24963d510c7ef59067428d3b082d3 Mon Sep 17 00:00:00 2001
> >> From: Steve French 
> >> Date: Thu, 17 May 2018 21:16:55 -0500
> >> Subject: [PATCH] smb3: Add ftrace tracepoints for improved SMB3 debugging
> >>
> >> Although dmesg logs and wireshark network traces can be
> >> helpful, being able to dynamically enable/disable tracepoints
> >> (in this case via the kernel ftrace mechanism) can also be
> >> helpful in more quickly debugging problems, and more
> >> selectively tracing the events related to the bug report.
> >>
> >> This patch adds 12 ftrace tracepoints to cifs.ko for SMB3 events
> >> in some obvious locations.  Subsequent patches will add more
> >> as needed.
> >>
> >> Example use:
> >>trace-cmd record -e cifs
> >>
> >>trace-cmd show
> >
> > pardon my ignorance, but are these tracepoints usable with other tracing
> > frameworks like Systemtap?
> >
> > Last time I checked, Systemtap looked like *the* tool.

Systemtap is great when you have a need for custom tracing. But for
day-to-day kernel development, tracepoints are far more useful
because they are always there and can cover all the common
situations that you need to trace.

And when it comes to debugging a one-off user problem when the user
knows nothing about systemtap?  Nothing beats asking the user
to run a trace on built-in tracepoints, reproduce the problem and
send the trace report back as per the above example.

> > Is there a generic trace
> > point infrastructure that tracing tools can consume, so we're not tied to
> > ftrace?
> 
> At the kernel filesystem/mm summit a few recommended using ftrace
> (trace-cmd).  Don't know what
> the thinking is about this vs. systemtap these days.  There was a nice
> three part series
> describing ftrace/trace-cmd on lwn
> (https://old.lwn.net/Articles/365835/) a while ago.
> 
> In terms of useability "trace-cmd" looked good to me and much more
> powerful than the
> current dmesg based printk style debugging.

And then you learn about trace_printk() for putting custom one-off
debug into the tracepoint stream and wonder why you didn't know
about this years ago :P

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: Tasks RCU vs Preempt RCU

[Joel Fernandes]

On Fri, May 18, 2018 at 07:29:18PM -0700, Paul E. McKenney wrote:
> On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote:
> > Hi,
> > 
> > I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows
> > tasks to be preempted in read-sections, can we not just reuse that mechanism
> > for the trampolines since we track all preempted tasks so we would wait on
> > all tasks preempted within a trampoline?
> > 
> > I am trying to understand what will _not_ work if we did that.. I'm guessing
> > the answer is that that would mean the trampoline has to be wrapped with
> > rcu_read_{lock,unlock} which may add some overhead, but please let me know
> > if I'm missing something else..
> > 
> > The advantage I guess is possible elimination of an RCU variant, and also
> > possibly eliminating the tasks RCU thread that monitors.. Anyway I was
> > thinking more in terms of the effort of reduction of the RCU flavors etc and
> > reducing complexity ideas.
> 
> The problem is that if they are preempted while executing in a trampoline,
> RCU-preempt doesn't queue them nor does it wait on them.

Not if they are wrapped with rcu_read_lock and rcu_read_unlock? From what I
can see, you are preparing a list of blocked tasks that would keep the grace 
period
from finishing in rcu_preempt_ctxt_queue?

> And the problem with wrapping them with rcu_read_{lock,unlock} is that
> there would be a point before the trampoline executed rcu_read_lock()
> but while it was on the trampoline.  Nothing good comes from this.  ;-)

Yes, I see what you're saying. The data being protected and freed in this
case is the code so relying on it to do the rcu_read_lock seems infeasible.
Conceptually atleast, I feel this can be fixed by cleverly implementing
trampolines such that the rcu_read_lock isn't done during the trampoline
execution. But I am not very experienced with how the trampolines work to say
definitely whether it is or isn't possible or worth it. But atleast I felt it
was a worthwhile food for thought ;)

I actually want to trace out the trampoline executing as it pertains to RCU,
with your latest rcu/dev.. I think it will be fun :)

thanks!

 - Joel

Re: Tasks RCU vs Preempt RCU

[Joel Fernandes]

On Fri, May 18, 2018 at 07:29:18PM -0700, Paul E. McKenney wrote:
> On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote:
> > Hi,
> > 
> > I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows
> > tasks to be preempted in read-sections, can we not just reuse that mechanism
> > for the trampolines since we track all preempted tasks so we would wait on
> > all tasks preempted within a trampoline?
> > 
> > I am trying to understand what will _not_ work if we did that.. I'm guessing
> > the answer is that that would mean the trampoline has to be wrapped with
> > rcu_read_{lock,unlock} which may add some overhead, but please let me know
> > if I'm missing something else..
> > 
> > The advantage I guess is possible elimination of an RCU variant, and also
> > possibly eliminating the tasks RCU thread that monitors.. Anyway I was
> > thinking more in terms of the effort of reduction of the RCU flavors etc and
> > reducing complexity ideas.
> 
> The problem is that if they are preempted while executing in a trampoline,
> RCU-preempt doesn't queue them nor does it wait on them.

Not if they are wrapped with rcu_read_lock and rcu_read_unlock? From what I
can see, you are preparing a list of blocked tasks that would keep the grace 
period
from finishing in rcu_preempt_ctxt_queue?

> And the problem with wrapping them with rcu_read_{lock,unlock} is that
> there would be a point before the trampoline executed rcu_read_lock()
> but while it was on the trampoline.  Nothing good comes from this.  ;-)

Yes, I see what you're saying. The data being protected and freed in this
case is the code so relying on it to do the rcu_read_lock seems infeasible.
Conceptually atleast, I feel this can be fixed by cleverly implementing
trampolines such that the rcu_read_lock isn't done during the trampoline
execution. But I am not very experienced with how the trampolines work to say
definitely whether it is or isn't possible or worth it. But atleast I felt it
was a worthwhile food for thought ;)

I actually want to trace out the trampoline executing as it pertains to RCU,
with your latest rcu/dev.. I think it will be fun :)

thanks!

 - Joel

[PATCH net-next] net: dsa: b53: Extend platform data to include DSA ports

[Florian Fainelli]

Provide a means for !OF platforms to supply their DSA platform data
configuration using the dsa_platform_data structure.

Signed-off-by: Florian Fainelli 
---
 include/linux/platform_data/b53.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/platform_data/b53.h 
b/include/linux/platform_data/b53.h
index 69d279c0da96..8eaef2f2b691 100644
--- a/include/linux/platform_data/b53.h
+++ b/include/linux/platform_data/b53.h
@@ -20,8 +20,12 @@
 #define __B53_H
 
 #include 
+#include 
 
 struct b53_platform_data {
+   /* Must be first such that dsa_register_switch() can access it */
+   struct dsa_chip_data cd;
+
u32 chip_id;
u16 enabled_ports;
 
-- 
2.14.1

[PATCH net-next] net: dsa: b53: Extend platform data to include DSA ports

[Florian Fainelli]

Provide a means for !OF platforms to supply their DSA platform data
configuration using the dsa_platform_data structure.

Signed-off-by: Florian Fainelli 
---
 include/linux/platform_data/b53.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/platform_data/b53.h 
b/include/linux/platform_data/b53.h
index 69d279c0da96..8eaef2f2b691 100644
--- a/include/linux/platform_data/b53.h
+++ b/include/linux/platform_data/b53.h
@@ -20,8 +20,12 @@
 #define __B53_H
 
 #include 
+#include 
 
 struct b53_platform_data {
+   /* Must be first such that dsa_register_switch() can access it */
+   struct dsa_chip_data cd;
+
u32 chip_id;
u16 enabled_ports;
 
-- 
2.14.1

Re: [PATCH 14/14] net: sched: implement delete for all actions

[Marcelo Ricardo Leitner]

On Wed, May 16, 2018 at 12:58:38PM +0300, Vlad Buslov wrote:
>
> On Wed 16 May 2018 at 09:48, Jiri Pirko  wrote:
> > Mon, May 14, 2018 at 04:27:15PM CEST, vla...@mellanox.com wrote:
> >>Implement delete function that is required to delete actions without
> >>holding rtnl lock. Use action API function that atomically deletes action
> >>only if it is still in action idr. This implementation prevents concurrent
> >>threads from deleting same action twice.
> >>
> >>Signed-off-by: Vlad Buslov 
> >>---
> >> net/sched/act_bpf.c|  8 
> >> net/sched/act_connmark.c   |  8 
> >> net/sched/act_csum.c   |  8 
> >> net/sched/act_gact.c   |  8 
> >> net/sched/act_ife.c|  8 
> >> net/sched/act_ipt.c| 16 
> >> net/sched/act_mirred.c |  8 
> >> net/sched/act_nat.c|  8 
> >> net/sched/act_pedit.c  |  8 
> >> net/sched/act_police.c |  8 
> >> net/sched/act_sample.c |  8 
> >> net/sched/act_simple.c |  8 
> >> net/sched/act_skbedit.c|  8 
> >> net/sched/act_skbmod.c |  8 
> >> net/sched/act_tunnel_key.c |  8 
> >> net/sched/act_vlan.c   |  8 
> >> 16 files changed, 136 insertions(+)
> >>
> >>diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
> >>index 0bf4ecf..36f7f66 100644
> >>--- a/net/sched/act_bpf.c
> >>+++ b/net/sched/act_bpf.c
> >>@@ -394,6 +394,13 @@ static int tcf_bpf_search(struct net *net, struct 
> >>tc_action **a, u32 index,
> >>return tcf_idr_search(tn, a, index);
> >> }
> >>
> >>+static int tcf_bpf_delete(struct net *net, u32 index)
> >>+{
> >>+   struct tc_action_net *tn = net_generic(net, bpf_net_id);
> >>+
> >>+   return tcf_idr_find_delete(tn, index);
> >>+}
> >>+
> >> static struct tc_action_ops act_bpf_ops __read_mostly = {
> >>.kind   =   "bpf",
> >>.type   =   TCA_ACT_BPF,
> >>@@ -404,6 +411,7 @@ static struct tc_action_ops act_bpf_ops __read_mostly = 
> >>{
> >>.init   =   tcf_bpf_init,
> >>.walk   =   tcf_bpf_walker,
> >>.lookup =   tcf_bpf_search,
> >>+   .delete =   tcf_bpf_delete,
> >
> > I wonder, right before this patch, how the idr index got removed?
> > delete op is NULL and I didn't find anyone else to do it.

AFAICT this also means it is leaking idr's till this patch is applied.
Maybe I missed something.

> >
> > Also, after this patch, does it make sense to have following check in
> > tcf_action_del_1()?
> >
> >if (ops->delete)
> >err = ops->delete(net, index);
> >
> > Looks like ops->delete is non-null for all.
> >
> > Seems to me that you need to introduce this patch filling up the delete
> > op in all acts and only after that introduce a code that actually calls
> > it.
>
> Already moved this for V2 patchset to:
>   - Add delete callback to ops and implement it for all actions in single
>   patch.
>   - Move this patch before delete first use.
>
> Will now remove the conditional as well.
>
> >
> > [...]
>

Re: [PATCH 14/14] net: sched: implement delete for all actions

[Marcelo Ricardo Leitner]

On Wed, May 16, 2018 at 12:58:38PM +0300, Vlad Buslov wrote:
>
> On Wed 16 May 2018 at 09:48, Jiri Pirko  wrote:
> > Mon, May 14, 2018 at 04:27:15PM CEST, vla...@mellanox.com wrote:
> >>Implement delete function that is required to delete actions without
> >>holding rtnl lock. Use action API function that atomically deletes action
> >>only if it is still in action idr. This implementation prevents concurrent
> >>threads from deleting same action twice.
> >>
> >>Signed-off-by: Vlad Buslov 
> >>---
> >> net/sched/act_bpf.c|  8 
> >> net/sched/act_connmark.c   |  8 
> >> net/sched/act_csum.c   |  8 
> >> net/sched/act_gact.c   |  8 
> >> net/sched/act_ife.c|  8 
> >> net/sched/act_ipt.c| 16 
> >> net/sched/act_mirred.c |  8 
> >> net/sched/act_nat.c|  8 
> >> net/sched/act_pedit.c  |  8 
> >> net/sched/act_police.c |  8 
> >> net/sched/act_sample.c |  8 
> >> net/sched/act_simple.c |  8 
> >> net/sched/act_skbedit.c|  8 
> >> net/sched/act_skbmod.c |  8 
> >> net/sched/act_tunnel_key.c |  8 
> >> net/sched/act_vlan.c   |  8 
> >> 16 files changed, 136 insertions(+)
> >>
> >>diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
> >>index 0bf4ecf..36f7f66 100644
> >>--- a/net/sched/act_bpf.c
> >>+++ b/net/sched/act_bpf.c
> >>@@ -394,6 +394,13 @@ static int tcf_bpf_search(struct net *net, struct 
> >>tc_action **a, u32 index,
> >>return tcf_idr_search(tn, a, index);
> >> }
> >>
> >>+static int tcf_bpf_delete(struct net *net, u32 index)
> >>+{
> >>+   struct tc_action_net *tn = net_generic(net, bpf_net_id);
> >>+
> >>+   return tcf_idr_find_delete(tn, index);
> >>+}
> >>+
> >> static struct tc_action_ops act_bpf_ops __read_mostly = {
> >>.kind   =   "bpf",
> >>.type   =   TCA_ACT_BPF,
> >>@@ -404,6 +411,7 @@ static struct tc_action_ops act_bpf_ops __read_mostly = 
> >>{
> >>.init   =   tcf_bpf_init,
> >>.walk   =   tcf_bpf_walker,
> >>.lookup =   tcf_bpf_search,
> >>+   .delete =   tcf_bpf_delete,
> >
> > I wonder, right before this patch, how the idr index got removed?
> > delete op is NULL and I didn't find anyone else to do it.

AFAICT this also means it is leaking idr's till this patch is applied.
Maybe I missed something.

> >
> > Also, after this patch, does it make sense to have following check in
> > tcf_action_del_1()?
> >
> >if (ops->delete)
> >err = ops->delete(net, index);
> >
> > Looks like ops->delete is non-null for all.
> >
> > Seems to me that you need to introduce this patch filling up the delete
> > op in all acts and only after that introduce a code that actually calls
> > it.
>
> Already moved this for V2 patchset to:
>   - Add delete callback to ops and implement it for all actions in single
>   patch.
>   - Move this patch before delete first use.
>
> Will now remove the conditional as well.
>
> >
> > [...]
>

Re: [PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

[Randy Dunlap]

On 05/17/18 22:10, Masahiro Yamada wrote:
> Hi Randy,
> 
> 2018-04-07 6:37 GMT+09:00 Randy Dunlap :
>> On 03/14/2018 10:50 PM, Masahiro Yamada wrote:
>>> 2018-03-13 11:30 GMT+09:00 Randy Dunlap :
 From: Randy Dunlap 

 Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
 that other required files are present, but none of these check that
 pkg-config itself is present.  Add a check for all 4 of these targets.

 Fixes kernel bugzilla #77511:
 https://bugzilla.kernel.org/show_bug.cgi?id=77511

 Signed-off-by: Randy Dunlap 
 ---
 v2: use 'command -v' instead of 'which'

 I'm also OK with just documenting the pkg-config requirement in
 Documentation/Changes (= Documentation/process/changes.rst).

  scripts/kconfig/Makefile   |   15 ++-
  scripts/kconfig/check-pkgconfig.sh |   12 
  2 files changed, 26 insertions(+), 1 deletion(-)

 --- lnx-416-rc3.orig/scripts/kconfig/Makefile
 +++ lnx-416-rc3/scripts/kconfig/Makefile
 @@ -160,6 +160,9 @@ help:
 @echo  '  xenconfig   - Enable additional options for xen dom0 
 and guest kernel support'
 @echo  '  tinyconfig  - Configure the tiniest possible kernel'

 +# pkg-config check
 +check-pkgconfig  := $(srctree)/$(src)/check-pkgconfig.sh
 +
  # lxdialog stuff
  check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh

 @@ -205,7 +208,17 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)
  $(obj)/dochecklxdialog:
 $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
 $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)

 -always := dochecklxdialog
 +# Check that we have pkg-config (used by each of menu/n/g/xconfig)
 +PHONY += $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, mconf.o): $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, nconf.o): $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, gconf.o): $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, qconf.o): $(obj)/docheckpkgconfig
 +
 +$(obj)/docheckpkgconfig:
 +   $(Q)$(CONFIG_SHELL) $(check-pkgconfig)
 +
 +always := docheckpkgconfig dochecklxdialog
>>>
>>>
>>> I did not test this patch, but does this check work as expected?
>>>
>>> Probably we want to run 'docheckpkgconfig'
>>> before 'dochecklxdiag', '.tmp_gtkcheck', '.tmp_qtcheck', etc.
>>> But, I do not see such dependencies.
>>>
>>>
>>> Also, if we make 'pkg-config' mandatory,
>>> should we entirely drop fall-back logics like follows?
>>>
>>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L10
>>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L29
>>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/Makefile#L230
>>>
>>>
>>> What do you think?
>>>
>>
>> Hi,
>>
>> I'm willing to keep patching/testing on this, but both pkg-config and depmod
>> (for depmod, see: https://bugzilla.kernel.org/show_bug.cgi?id=198965)
>> are basic requirements IMO, so just documenting their requirements is good
>> enough to me, but might not be good enough for some users.
>>
>> Comments?
> 
> Sorry for late comments.
> 
> OK, I am fine with making pkg-config a requirement.
> (and it should be documented)
> 
> But, I'd like to clean-up scripts/kconfig/Makefile first.
> It is already cluttered, and hesitate to add new code based on that.
> I posted the patches.
> 
> Could you send v3 after the cleaning work is done?

Sure, I'll give it a try.

thanks.
-- 
~Randy

Re: [PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

[Randy Dunlap]

On 05/17/18 22:10, Masahiro Yamada wrote:
> Hi Randy,
> 
> 2018-04-07 6:37 GMT+09:00 Randy Dunlap :
>> On 03/14/2018 10:50 PM, Masahiro Yamada wrote:
>>> 2018-03-13 11:30 GMT+09:00 Randy Dunlap :
 From: Randy Dunlap 

 Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
 that other required files are present, but none of these check that
 pkg-config itself is present.  Add a check for all 4 of these targets.

 Fixes kernel bugzilla #77511:
 https://bugzilla.kernel.org/show_bug.cgi?id=77511

 Signed-off-by: Randy Dunlap 
 ---
 v2: use 'command -v' instead of 'which'

 I'm also OK with just documenting the pkg-config requirement in
 Documentation/Changes (= Documentation/process/changes.rst).

  scripts/kconfig/Makefile   |   15 ++-
  scripts/kconfig/check-pkgconfig.sh |   12 
  2 files changed, 26 insertions(+), 1 deletion(-)

 --- lnx-416-rc3.orig/scripts/kconfig/Makefile
 +++ lnx-416-rc3/scripts/kconfig/Makefile
 @@ -160,6 +160,9 @@ help:
 @echo  '  xenconfig   - Enable additional options for xen dom0 
 and guest kernel support'
 @echo  '  tinyconfig  - Configure the tiniest possible kernel'

 +# pkg-config check
 +check-pkgconfig  := $(srctree)/$(src)/check-pkgconfig.sh
 +
  # lxdialog stuff
  check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh

 @@ -205,7 +208,17 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)
  $(obj)/dochecklxdialog:
 $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
 $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)

 -always := dochecklxdialog
 +# Check that we have pkg-config (used by each of menu/n/g/xconfig)
 +PHONY += $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, mconf.o): $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, nconf.o): $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, gconf.o): $(obj)/docheckpkgconfig
 +$(addprefix $(obj)/, qconf.o): $(obj)/docheckpkgconfig
 +
 +$(obj)/docheckpkgconfig:
 +   $(Q)$(CONFIG_SHELL) $(check-pkgconfig)
 +
 +always := docheckpkgconfig dochecklxdialog
>>>
>>>
>>> I did not test this patch, but does this check work as expected?
>>>
>>> Probably we want to run 'docheckpkgconfig'
>>> before 'dochecklxdiag', '.tmp_gtkcheck', '.tmp_qtcheck', etc.
>>> But, I do not see such dependencies.
>>>
>>>
>>> Also, if we make 'pkg-config' mandatory,
>>> should we entirely drop fall-back logics like follows?
>>>
>>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L10
>>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L29
>>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/Makefile#L230
>>>
>>>
>>> What do you think?
>>>
>>
>> Hi,
>>
>> I'm willing to keep patching/testing on this, but both pkg-config and depmod
>> (for depmod, see: https://bugzilla.kernel.org/show_bug.cgi?id=198965)
>> are basic requirements IMO, so just documenting their requirements is good
>> enough to me, but might not be good enough for some users.
>>
>> Comments?
> 
> Sorry for late comments.
> 
> OK, I am fine with making pkg-config a requirement.
> (and it should be documented)
> 
> But, I'd like to clean-up scripts/kconfig/Makefile first.
> It is already cluttered, and hesitate to add new code based on that.
> I posted the patches.
> 
> Could you send v3 after the cleaning work is done?

Sure, I'll give it a try.

thanks.
-- 
~Randy

Re: [PATCH v3 1/2] soc: imx: gpcv2: Do not pass static memory as platform data

[Andrey Smirnov]

On Tue, Apr 10, 2018 at 11:32 AM, Andrey Smirnov
 wrote:
> Platform device core assumes the ownership of dev.platform_data as
> well as that it is dynamically allocated and it will try to kfree it
> as a part of platform_device_release(). Change the code to use
> platform_device_add_data() n instead of a pointer to a static memory
> to avoid causing a BUG() when calling platform_device_put().
>
> The problem can be reproduced by artificially enabling the error path
> of platform_device_add() call (around line 357).
>
> Note that this change also allows us to constify imx7_pgc_domains,
> since we no longer need to be able to modify it.
>

Shawn,

What's the status of these two patches? Do I need to change anything
or are they good to go?

Thanks,
Andrey Smirnov

Re: [PATCH v3 1/2] soc: imx: gpcv2: Do not pass static memory as platform data

[Andrey Smirnov]

On Tue, Apr 10, 2018 at 11:32 AM, Andrey Smirnov
 wrote:
> Platform device core assumes the ownership of dev.platform_data as
> well as that it is dynamically allocated and it will try to kfree it
> as a part of platform_device_release(). Change the code to use
> platform_device_add_data() n instead of a pointer to a static memory
> to avoid causing a BUG() when calling platform_device_put().
>
> The problem can be reproduced by artificially enabling the error path
> of platform_device_add() call (around line 357).
>
> Note that this change also allows us to constify imx7_pgc_domains,
> since we no longer need to be able to modify it.
>

Shawn,

What's the status of these two patches? Do I need to change anything
or are they good to go?

Thanks,
Andrey Smirnov

Re: [PATCH 12/14] net: sched: retry action check-insert on concurrent modification

[Marcelo Ricardo Leitner]

On Wed, May 16, 2018 at 03:21:35PM +0200, Jiri Pirko wrote:
...
> int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index,
>   struct tc_action **a, int bind)

Considering we don't have any other variant of it, maybe just
"tcf_idr_alloc()" instead?

Re: [PATCH 12/14] net: sched: retry action check-insert on concurrent modification

[Marcelo Ricardo Leitner]

On Wed, May 16, 2018 at 03:21:35PM +0200, Jiri Pirko wrote:
...
> int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index,
>   struct tc_action **a, int bind)

Considering we don't have any other variant of it, maybe just
"tcf_idr_alloc()" instead?

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

[Marcelo Ricardo Leitner]

On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
> Substitute calls to action insert function with calls to action insert
> unique function that warns if insertion overwrites index in idr.

I know this patch may be gone on V2, but a general comment, please use
the function names themselves instead of a textualized version. I.e.,
s/action insert unique/tcf_idr_insert_unique/

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

[Marcelo Ricardo Leitner]

On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote:
> Substitute calls to action insert function with calls to action insert
> unique function that warns if insertion overwrites index in idr.

I know this patch may be gone on V2, but a general comment, please use
the function names themselves instead of a textualized version. I.e.,
s/action insert unique/tcf_idr_insert_unique/