Re: [PATCH 06/16] x86/mm/ldt: Reserve high address-space range for the LDT
On Tue, Jan 16, 2018 at 02:51:45PM -0800, Andy Lutomirski wrote: > On Tue, Jan 16, 2018 at 8:52 AM, Peter Zijlstra wrote: > > On Tue, Jan 16, 2018 at 05:36:49PM +0100, Joerg Roedel wrote: > >> From: Joerg Roedel > >> > >> Reserve 2MB/4MB of address space for mapping the LDT to > >> user-space. > > > > LDT is 64k, we need 2 per CPU, and NR_CPUS <= 64 on 32bit, that gives > > 64K*2*64=8M > 2M. > > If this works like it does on 64-bit, it only needs 128k regardless of > the number of CPUs. The LDT mapping is specific to the mm. Ah, then I got my LDT things confused again... which is certainly possible, we had a few too many variants back then.
Re: [PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings
Hi Jacopo,
On Tue, Jan 16, 2018 at 10:44:53PM +0100, Jacopo Mondi wrote:
> Add bindings documentation for Renesas Capture Engine Unit (CEU).
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
> Acked-by: Hans Verkuil
> ---
> .../devicetree/bindings/media/renesas,ceu.txt | 81
> ++
> 1 file changed, 81 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> new file mode 100644
> index 000..590ee27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -0,0 +1,81 @@
> +Renesas Capture Engine Unit (CEU)
> +--
> +
> +The Capture Engine Unit is the image capture interface found in the Renesas
> +SH Mobile and RZ SoCs.
> +
> +The interface supports a single parallel input with data bus width of 8 or 16
> +bits.
> +
> +Required properties:
> +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1-H
> + and RZ/A1-M SoCs.
> +- reg: Registers address base and size.
> +- interrupts: The interrupt specifier.
> +
> +The CEU supports a single parallel input and should contain a single 'port'
> +subnode with a single 'endpoint'. Connection to input devices are modeled
> +according to the video interfaces OF bindings specified in:
> +Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Optional endpoint properties applicable to parallel input bus described in
> +the above mentioned "video-interfaces.txt" file are supported.
> +
> +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
> respectively.
> + If property is not present, default is active high.
> +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
> respectively.
> + If property is not present, default is active high.
Does the hardware support Bt.656? If it does, you need to tell the
difference between the parallel interface with default sync polarity and
Bt.656 interfaces. With the above it's ambiguous.
> +
> +Example:
> +
> +The example describes the connection between the Capture Engine Unit and an
> +OV7670 image sensor connected to i2c1 interface.
> +
> +ceu: ceu@e821 {
> + reg = <0xe821 0x209c>;
> + compatible = "renesas,r7s72100-ceu";
> + interrupts = ;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vio_pins>;
> +
> + status = "okay";
> +
> + port {
> + ceu_in: endpoint {
> + remote-endpoint = <&ov7670_out>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> +};
> +
> +i2c1: i2c@fcfee400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins>;
> +
> + status = "okay";
> +
> + clock-frequency = <10>;
> +
> + ov7670: camera@21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vio_pins>;
> +
> + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov7670_out: endpoint {
> + remote-endpoint = <&ceu_in>;
> +
> + hsync-active = <1>;
> + vsync-active = <0>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
Re: [PATCH] lightnvm/pblk-gc: Delete an error message for a failed memory allocation in pblk_gc_line_prepare_ws()
> On 16 Jan 2018, at 22.10, SF Markus Elfring
> wrote:
>
> From: Markus Elfring
> Date: Tue, 16 Jan 2018 22:00:15 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/lightnvm/pblk-gc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/lightnvm/pblk-gc.c b/drivers/lightnvm/pblk-gc.c
> index 9c8e114c8a54..54cdb4360366 100644
> --- a/drivers/lightnvm/pblk-gc.c
> +++ b/drivers/lightnvm/pblk-gc.c
> @@ -147,10 +147,8 @@ static void pblk_gc_line_prepare_ws(struct work_struct
> *work)
> int ret;
>
> invalid_bitmap = kmalloc(lm->sec_bitmap_len, GFP_KERNEL);
> - if (!invalid_bitmap) {
> - pr_err("pblk: could not allocate GC invalid bitmap\n");
> + if (!invalid_bitmap)
> goto fail_free_ws;
> - }
>
> emeta_buf = pblk_malloc(lm->emeta_len[0], l_mg->emeta_alloc_type,
> GFP_KERNEL);
> --
> 2.15.1
Looks good to me.
Reviewed-by: Javier González
signature.asc
Description: Message signed with OpenPGP
[PATCH v5 0/3] Add support for Hi3660 mailbox driver
Hi3660 mailbox controller is used to send message within multiple processors, MCU, HIFI, etc. This patch series is to implement an initial version for Hi3660 mailbox driver with "automatic acknowledge" mode. The patch set have been verified with Hi3660 stub clock driver, so we can send message to MCU to execute CPU frequency scaling. This is tested on 96boards Hikey960. Changes from v4: * According to Jassi suggestion, refactored mailbox driver and removed "inline" for function declaration; Changes from v3: * According to Jassi suggestion, refined structure name to "struct hi3660_chan_info"; * According to Jassi suggestion, moved channel 'lock'+'acquire' operations into .startup(); Changes from v2: * According to Mark Rutland suggestions, removed sev()/wfe() from driver, the system has no two masters sharing the same channel for data transferring so we don't need these instructions; * Refined DT binding and doc according to Rob suggestions; * Refined driver according to Julien suggestions; Changes from v1: * Added cover letter to track the changelog; * Added document for DT binding; * Refactored and simplized mailbox driver with "automatic ack" mode; * Refined commit logs for patches; Kaihua Zhong (2): mailbox: Add support for Hi3660 mailbox dts: arm64: Add mailbox binding for hi3660 Leo Yan (1): dt-bindings: mailbox: Introduce Hi3660 controller binding .../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 + drivers/mailbox/Kconfig| 8 + drivers/mailbox/Makefile | 2 + drivers/mailbox/hi3660-mailbox.c | 316 + 5 files changed, 385 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt create mode 100644 drivers/mailbox/hi3660-mailbox.c -- 1.9.1
Re: [RFC PATCH 5/9] media: vb2: add support for requests
On Tue, Jan 16, 2018 at 7:37 PM, Hans Verkuil wrote:
> On 01/16/2018 10:39 AM, Alexandre Courbot wrote:
>> On Mon, Jan 15, 2018 at 6:07 PM, Hans Verkuil wrote:
>>> On 01/15/2018 09:24 AM, Alexandre Courbot wrote:
On Fri, Jan 12, 2018 at 7:49 PM, Hans Verkuil wrote:
> On 12/15/17 08:56, Alexandre Courbot wrote:
>> Add throttling support for buffers when requests are in use on a given
>> queue. Buffers associated to a request are kept into the vb2 queue until
>> the request becomes active, at which point all the buffers are passed to
>> the driver. The queue can also signal that is has processed all of a
>> request's buffers.
>>
>> Also add support for the request parameter when handling the QBUF ioctl.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/media/v4l2-core/videobuf2-core.c | 59
>>
>> drivers/media/v4l2-core/videobuf2-v4l2.c | 29 +++-
>> include/media/videobuf2-core.h | 25 +-
>> 3 files changed, 104 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index cb115ba6a1d2..c01038b7962a 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -898,6 +898,8 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
>> vb2_buffer_state state)
>> state != VB2_BUF_STATE_REQUEUEING))
>> state = VB2_BUF_STATE_ERROR;
>>
>> + WARN_ON(vb->request != q->cur_req);
>
> What's the reason for this WARN_ON? It's not immediately obvious to me.
This is a safeguard against driver bugs: a buffer should not complete
unless it is part of the request being currently processed.
>
>> +
>> #ifdef CONFIG_VIDEO_ADV_DEBUG
>> /*
>>* Although this is not a callback, it still does have to balance
>> @@ -920,6 +922,13 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
>> vb2_buffer_state state)
>> /* Add the buffer to the done buffers list */
>> list_add_tail(&vb->done_entry, &q->done_list);
>> vb->state = state;
>> +
>> + if (q->cur_req) {
>> + WARN_ON(q->req_buf_cnt < 1);
>> +
>> + if (--q->req_buf_cnt == 0)
>> + q->cur_req = NULL;
>> + }
>> }
>> atomic_dec(&q->owned_by_drv_count);
>> spin_unlock_irqrestore(&q->done_lock, flags);
>> @@ -1298,6 +1307,16 @@ int vb2_core_prepare_buf(struct vb2_queue *q,
>> unsigned int index, void *pb)
>> }
>> EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
>>
>> +static void vb2_queue_enqueue_current_buffers(struct vb2_queue *q)
>> +{
>> + struct vb2_buffer *vb;
>> +
>> + list_for_each_entry(vb, &q->queued_list, queued_entry) {
>> + if (vb->request == q->cur_req)
>> + __enqueue_in_driver(vb);
>> + }
>> +}
>
> I think this will clash big time with the v4l2 fence patch series...
Indeed, but on the other hand I was not a big fan of going through the
whole list. :) So I welcome the extra throttling introduced by the
fence series.
>>>
>>> There is only throttling if fences are used by userspace. Otherwise there
>>> is no change.
>>>
>
>> +
>> /**
>> * vb2_start_streaming() - Attempt to start streaming.
>> * @q: videobuf2 queue
>> @@ -1318,8 +1337,7 @@ static int vb2_start_streaming(struct vb2_queue *q)
>>* If any buffers were queued before streamon,
>>* we can now pass them to driver for processing.
>>*/
>> - list_for_each_entry(vb, &q->queued_list, queued_entry)
>> - __enqueue_in_driver(vb);
>> + vb2_queue_enqueue_current_buffers(q);
>>
>> /* Tell the driver to start streaming */
>> q->start_streaming_called = 1;
>> @@ -1361,7 +1379,8 @@ static int vb2_start_streaming(struct vb2_queue *q)
>> return ret;
>> }
>>
>> -int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
>> +int vb2_core_qbuf(struct vb2_queue *q, unsigned int index,
>> + struct media_request *req, void *pb)
>> {
>> struct vb2_buffer *vb;
>> int ret;
>> @@ -1392,6 +1411,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned
>> int index, void *pb)
>> q->queued_count++;
>> q->waiting_for_buffers = false;
>> vb->state = VB2_BUF_STATE_QUEUED;
>> + vb->request = req;
>>
>> if (pb)
>> call_void_bufop(q, copy_timestamp, vb, pb);
>> @@ -1401,8 +1421,11 @@ int vb2_core_qbuf(struct vb2
[PATCH v5 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding
Introduce a binding for the Hi3660 mailbox controller, the mailbox is
used within application processor (AP), communication processor (CP),
HIFI and MCU, etc.
Acked-by: Rob Herring
Signed-off-by: Leo Yan
---
.../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
new file mode 100644
index 000..3e5b453
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
@@ -0,0 +1,51 @@
+Hisilicon Hi3660 Mailbox Controller
+
+Hisilicon Hi3660 mailbox controller supports up to 32 channels. Messages
+are passed between processors, including application & communication
+processors, MCU, HIFI, etc. Each channel is unidirectional and accessed
+by using MMIO registers; it supports maximum to 8 words message.
+
+Controller
+--
+
+Required properties:
+- compatible: : Shall be "hisilicon,hi3660-mbox"
+- reg: : Offset and length of the device's register set
+- #mbox-cells: : Must be 3
+ <&phandle channel dst_irq ack_irq>
+ phandle : Label name of controller
+ channel : Channel number
+ dst_irq : Remote interrupt vector
+ ack_irq : Local interrupt vector
+
+- interrupts: : Contains the two IRQ lines for mailbox.
+
+Example:
+
+mailbox: mailbox@e896b000 {
+ compatible = "hisilicon,hi3660-mbox";
+ reg = <0x0 0xe896b000 0x0 0x1000>;
+ interrupts = <0x0 0xc0 0x4>,
+<0x0 0xc1 0x4>;
+ #mbox-cells = <3>;
+};
+
+Client
+--
+
+Required properties:
+- compatible : See the client docs
+- mboxes : Standard property to specify a Mailbox (See
./mailbox.txt)
+ Cells must match 'mbox-cells' (See Controller docs
above)
+
+Optional properties
+- mbox-names : Name given to channels seen in the 'mboxes' property.
+
+Example:
+
+stub_clock: stub_clock@e896b500 {
+ compatible = "hisilicon,hi3660-stub-clk";
+ reg = <0x0 0xe896b500 0x0 0x0100>;
+ #clock-cells = <1>;
+ mboxes = <&mailbox 13 3 0>;
+};
--
1.9.1
[PATCH v5 2/3] mailbox: Add support for Hi3660 mailbox
From: Kaihua Zhong
Hi3660 mailbox controller is used to send message within multiple
processors, MCU, HIFI, etc. It supports 32 mailbox channels and every
channel can only be used for single transferring direction. Once the
channel is enabled, it needs to specify the destination interrupt and
acknowledge interrupt, these two interrupt vectors are used to create
the connection between the mailbox and interrupt controllers.
The data transferring supports two modes, one is named as "automatic
acknowledge" mode so after send message the kernel doesn't need to wait
for acknowledge from remote and directly return; there have another mode
is to rely on handling interrupt for acknowledge.
This commit is for initial version driver, which only supports
"automatic acknowledge" mode to support CPU clock, which is the only
one consumer to use mailbox and has been verified. Later may enhance
this driver for interrupt mode (e.g. for supporting HIFI).
Signed-off-by: Leo Yan
Signed-off-by: Ruyi Wang
Signed-off-by: Kaihua Zhong
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/hi3660-mailbox.c | 316 +++
3 files changed, 326 insertions(+)
create mode 100644 drivers/mailbox/hi3660-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f152..de8390d4 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -108,6 +108,14 @@ config TI_MESSAGE_MANAGER
multiple processors within the SoC. Select this driver if your
platform has support for the hardware block.
+config HI3660_MBOX
+ tristate "Hi3660 Mailbox"
+ depends on ARCH_HISI && OF
+ help
+ An implementation of the hi3660 mailbox. It is used to send message
+ between application processors and other processors/MCU/DSP. Select
+ Y here if you want to use Hi3660 mailbox controller.
+
config HI6220_MBOX
tristate "Hi6220 Mailbox"
depends on ARCH_HISI
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4896f8d..cc23c3a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_TI_MESSAGE_MANAGER) += ti-msgmgr.o
obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
+obj-$(CONFIG_HI3660_MBOX) += hi3660-mailbox.o
+
obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c
new file mode 100644
index 000..d6b1600
--- /dev/null
+++ b/drivers/mailbox/hi3660-mailbox.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Hisilicon Limited.
+// Copyright (c) 2017 Linaro Limited.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mailbox.h"
+
+#define MBOX_CHAN_MAX 32
+
+#define MBOX_RX0x0
+#define MBOX_TX0x1
+
+#define MBOX_BASE(mbox, ch)((mbox)->base + ((ch) * 0x40))
+#define MBOX_SRC_REG 0x00
+#define MBOX_DST_REG 0x04
+#define MBOX_DCLR_REG 0x08
+#define MBOX_DSTAT_REG 0x0c
+#define MBOX_MODE_REG 0x10
+#define MBOX_IMASK_REG 0x14
+#define MBOX_ICLR_REG 0x18
+#define MBOX_SEND_REG 0x1c
+#define MBOX_DATA_REG 0x20
+
+#define MBOX_IPC_LOCK_REG 0xa00
+#define MBOX_IPC_UNLOCK0x1acce551
+
+#define MBOX_AUTOMATIC_ACK 1
+
+#define MBOX_STATE_IDLEBIT(4)
+#define MBOX_STATE_ACK BIT(7)
+
+#define MBOX_MSG_LEN 8
+
+/**
+ * Hi3660 mailbox channel information
+ *
+ * A channel can be used for TX or RX, it can trigger remote
+ * processor interrupt to notify remote processor and can receive
+ * interrupt if has incoming message.
+ *
+ * @dst_irq: Interrupt vector for remote processor
+ * @ack_irq: Interrupt vector for local processor
+ */
+struct hi3660_chan_info {
+ unsigned int dst_irq;
+ unsigned int ack_irq;
+};
+
+/**
+ * Hi3660 mailbox controller data
+ *
+ * Mailbox controller includes 32 channels and can allocate
+ * channel for message transferring.
+ *
+ * @dev: Device to which it is attached
+ * @base: Base address of the register mapping region
+ * @chan: Representation of channels in mailbox controller
+ * @mchan: Representation of channel info
+ * @controller:Representation of a communication channel controller
+ */
+struct hi3660_mbox {
+ struct device *dev;
+ void __iomem *base;
+ struct mbox_chan chan[MBOX_CHAN_MAX];
+ struct hi3660_chan_info mchan[MBOX_CHAN_MAX];
+ struct mbox_controller controller;
+};
+
+static struct hi3660_mbox
[PATCH v5 3/3] dts: arm64: Add mailbox binding for hi3660
From: Kaihua Zhong
Add DT binding for mailbox driver.
Signed-off-by: Ruyi Wang
Signed-off-by: Kaihua Zhong
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 22570c3..1ef7b94 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -286,6 +286,14 @@
#reset-cells = <2>;
};
+ mailbox: mailbox@e896b000 {
+ compatible = "hisilicon,hi3660-mbox";
+ reg = <0x0 0xe896b000 0x0 0x1000>;
+ interrupts = ,
+;
+ #mbox-cells = <3>;
+ };
+
stub_clock: stub_clock@e896b500 {
compatible = "hisilicon,hi3660-stub-clk";
reg = <0x0 0xe896b500 0x0 0x0100>;
--
1.9.1
Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding library
On Tue, Jan 16, 2018 at 01:30:33PM -0700, Mathieu Poirier wrote: > On 16 January 2018 at 05:15, Jiri Olsa wrote: > > On Mon, Jan 15, 2018 at 11:13:05AM -0700, Mathieu Poirier wrote: > >> The Open CoreSight Decoding Library (openCSD) is a free and open > >> library to decode traces collected by the CoreSight hardware > >> infrastructure. > >> > >> This patch adds the required mechanic to recognise the presence > >> of the openCSD library on a system and set up miscellaneous flags > >> to be used in the compilation of the trace decoding feature. > >> > >> Signed-off-by: Mathieu Poirier > >> --- > >> tools/build/Makefile.feature | 6 -- > >> tools/build/feature/Makefile | 7 ++- > >> tools/build/feature/test-all.c| 5 + > >> tools/build/feature/test-libopencsd.c | 8 > >> tools/perf/Makefile.config| 25 + > >> tools/perf/Makefile.perf | 2 ++ > >> 6 files changed, 50 insertions(+), 3 deletions(-) > >> create mode 100644 tools/build/feature/test-libopencsd.c > >> > >> diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature > >> index e52fcefee379..dc3d97b248ab 100644 > >> --- a/tools/build/Makefile.feature > >> +++ b/tools/build/Makefile.feature > >> @@ -66,7 +66,8 @@ FEATURE_TESTS_BASIC := \ > >> bpf \ > >> sched_getcpu \ > >> sdt \ > >> -setns > >> +setns\ > >> + libopencsd > >> > >> # FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list > >> # of all feature tests > >> @@ -108,7 +109,8 @@ FEATURE_DISPLAY ?= \ > >> zlib \ > >> lzma \ > >> get_cpuid \ > >> - bpf > >> + bpf \ > >> + libopencsd > > > > we put in this list only generic libraries, this one seems arch > > specific please put it into FEATURE_TESTS_EXTRA list > > Humm... Jiri, > > I was thinking that libopencsd should fall in the same category as > libunwind-arm and libunwind-aarch64. Both are not architecture > specific and used to process traces acquired on ARM platforms. As > such I suggest to keep libopencsd as part of FEATURE_TESTS_BASIC and > remove it from under FEATURE_DISPLAY - how does that sound to you? > ok, that sounds good jirka
Re: LKML admins (syzbot emails are not delivered)
On Wed, Jan 17, 2018 at 12:13 AM, Theodore Ts'o wrote: > On Tue, Jan 16, 2018 at 09:31:26AM +0100, Dmitry Vyukov wrote: >> On Tue, Jan 16, 2018 at 8:12 AM, Theodore Ts'o wrote: >> > I just checked a recent report from the Syzbot, and it's not fixed. >> > The raw.log file still uses a Content-Type of >> > Application/Octet-stream. Worse the reproducer C source file has a >> > content type of Application/Octet-stream instead of the much more sane >> > Application/text. >> >> >> I will look into using a different mailing system which allows more >> control over email contents. >> A quick fix for raw.log will be to rename it to raw.log.txt. Not sure >> if text/plain repro.c.txt is better than application/octet-stream >> repro.c... > > My personal opinion is that if there is no way to force the content > type except by using magic extensions --- which is super-surprising to > me; that seems like a broken API and a feature request bug should be > filed against the relevant API --- using repro.c.txt would be the best > of bad alternatives. Someone is going to have to exit to a shell to > compile the repro, and renaming the filename isn't a big deal. The > Mail User Agent I use (mutt) allows me to specify the directory to > save the file, and gives me the opportunity to edit the filename, > before I save it. So at least for me, it really isn't a big deal for > you to use repro.c.txt. Good. I've made such change, it's now raw.log.txt and repro.c.txt: https://github.com/google/syzkaller/commit/afcb994770d7e0f4b88c623bec76fbdce57d3910 I've also mailed a change to appengine that supports *.c, *.log and *.patch as text/plain extensions. There does not seem to be any major objects to it, but it will probably take some time to be deployed in prod. After that I will rename them back.
Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE
On Thu 11-01-18 15:38:37, Anshuman Khandual wrote: > On 01/09/2018 09:43 PM, Michal Hocko wrote: [...] > > Did you manage to catch _who_ is requesting that anonymous mapping? Do > > you need a help with the debugging patch? > > Not yet, will get back on this. ping? -- Michal Hocko SUSE Labs
Re: WARNING in can_rcv
On 01/17/2018 08:12 AM, Eric Biggers wrote: On Wed, Jan 17, 2018 at 07:39:24AM +0100, Oliver Hartkopp wrote: On 01/16/2018 07:11 PM, Dmitry Vyukov wrote: On Tue, Jan 16, 2018 at 7:07 PM, Marc Kleine-Budde wrote: On 01/16/2018 06:58 PM, syzbot wrote: Hello, syzkaller hit the following crash on a8750ddca918032d6349adbf9a4b6555e7db20da git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. C reproducer is attached syzkaller reproducer is attached. See https://goo.gl/kgGztJ for information about syzkaller reproducers IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+4386709c0c1284dca...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. device eql entered promiscuous mode [ cut here ] PF_CAN: dropped non conform CAN skbuf: dev type 65534, len 42, datalen 0 WARNING: CPU: 0 PID: 3650 at net/can/af_can.c:729 can_rcv+0x1c5/0x200 net/can/af_can.c:724 Kernel panic - not syncing: panic_on_warn set ... Invalid packages generate a warning (WARN_ONCE()), and you have panic_on_warn active. Should we better silently drop these CAN packages? Hi, pr_warn_once() will be more appropriate. It prints a single line. The idea behind this WARN() is to detect really bad things that might have happen on network driver level: The CAN subsystem registers with dev_add_pack() for ETH_P_CAN and ETH_P_CANFD only. These ETH_P_ types are only allowed to be created by CAN network devices (like vcan, vxcan, and real CAN drivers). I don't have any strong opinion on using WARN() or pr_warn_once(). Is this detected violation worth using WARN(), as something already must have gone really wrong to trigger this issue? WARN() indicates a kernel bug. If it's instead "userspace did something stupid", or "someone sent some unexpected network packet", it needs to be pr_warn_once(), pr_warn_ratelimited(), or removed entirely. Ok. Thanks for the explanation! It is "some bogus network driver sent something unexpected" - but that does not harm the entire system. pr_warn_once() seems the right way to go then. Thanks, Oliver
Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU
Hi ming Thanks for your kindly response. On 01/17/2018 02:22 PM, Ming Lei wrote: > This warning can't be removed completely, for example, the CPU figured > in blk_mq_hctx_next_cpu(hctx) can be put on again just after the > following call returns and before __blk_mq_run_hw_queue() is scheduled > to run. > > kblockd_mod_delayed_work_on(blk_mq_hctx_next_cpu(hctx), > &hctx->run_work, msecs_to_jiffies(msecs)) We could use cpu_active in __blk_mq_run_hw_queue() to narrow the window. There is a big gap between cpu_online and cpu_active. rebind_workers is also between them. > > Just be curious how you trigger this issue? And is it triggered in CPU > hotplug stress test? Or in a normal use case? In fact, this is my own investigation about whether the .queue_rq to one hardware queue could be executed on the cpu where it is not mapped. Finally, found this hole when cpu hotplug. I did the test on NVMe device which has 1-to-1 mapping between cpu and hctx. - A special patch that could hold some requests on ctx->rq_list though .get_budget - A script issues IOs with fio - A script online/offline the cpus continuously At first, just the warning above. Then after this patch was introduced, panic came up. Thanks Jianchao
Re: [PATCH v2 11/10] objtool: Even more complex static block checks
On Tue, Jan 16, 2018 at 09:12:32PM -0600, Josh Poimboeuf wrote:
> On Tue, Jan 16, 2018 at 08:49:17PM +0100, Peter Zijlstra wrote:
> > Subject: objtool: Even more complex static block checks
> > From: Peter Zijlstra
> > Date: Tue Jan 16 20:17:01 CET 2018
> >
> > I've observed GCC transform:
> >
> > f()
> > {
> > if (!static_branch_unlikely())
> > return;
> >
> > static_assert();
> > A;
> > }
> >
> > g()
> > {
> > f();
> > }
> >
> > Into:
> >
> > f()
> > {
> > static_assert();
> > A;
> > }
> >
> > g()
> > {
> > if (static_branch_unlikely())
> > f();
> > }
> >
> > Which results in the assertion landing at f+0. The transformation is
> > valid and useful; it avoids a pointless CALL+RET sequence, so we'll
> > have to teach objtool how to deal with this.
> >
> > Do this by marking all CALL destinations with static_call when called
> > from a static_block and non_static_call when called outside a
> > static_block. This allows us to identify functions called exclusively
> > from a static_block and start them with a static_block.
>
> Ew... where'd you place the assertion to trigger this?
Its the patch I pastebin'ed you earlier, also see below.
> It's late and my brain has already clocked out, so I'll need to revisit
> this tomorrow. But now I'm wondering if my basic block idea would be a
> better way to solve this.
I would think basic-blocks are inside functions, and this patch goes
across functions, something you'd still need even if you had basic
blocks.
Also, basic blocks are non-trivial because they can overlap. I've
implemented something like that before for perf, see commit:
70fbe0574558 ("perf annotate: Add branch stack / basic block")
We could probably lift that code fairly easily.
---
Subject: jump_label: Add static assertion to every static_branch
From: Peter Zijlstra
Date: Tue Jan 16 15:27:36 CET 2018
for testing.. not sure we wants this in general
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/jump_label.h |1 +
include/linux/jump_label.h|8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -76,6 +76,7 @@ static __always_inline bool arch_static_
*
* Also works with static_cpu_has().
*/
+#define arch_static_assert arch_static_assert
static __always_inline void arch_static_assert(void)
{
asm volatile ("1:\n\t"
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -323,6 +323,10 @@ extern bool wrong_branch_error(void)
#ifdef HAVE_JUMP_LABEL
+#ifndef arch_static_assert
+#define arch_static_assert (void)
+#endif
+
/*
* Combine the right initial value (type) with the right branch order
* to generate the desired result.
@@ -388,7 +392,7 @@ extern bool wrong_branch_error(void)
branch = !arch_static_branch_jump(&(x)->key, true);
\
else
\
branch = wrong_branch_error();
\
- branch;
\
+ branch && (arch_static_assert(), true);
\
})
#define static_branch_unlikely(x)
\
@@ -400,7 +404,7 @@ extern bool wrong_branch_error(void)
branch = arch_static_branch(&(x)->key, false);
\
else
\
branch = wrong_branch_error();
\
- branch;
\
+ branch && (arch_static_assert(), true);
\
})
#else /* !HAVE_JUMP_LABEL */
> Josh
Re: LKML admins (syzbot emails are not delivered)
On Mon, Jan 15, 2018 at 5:38 PM, Eric W. Biederman wrote: > I am definitely not asking for expertise in the kernel. I am asking > for a human who wants to help track down bugs in the kernel. What is that additional information that you need and that syzbot currently does not provide?
Re: [PATCH v2 10/10] objtool: More complex static jump implementation
On Tue, Jan 16, 2018 at 09:05:31PM -0600, Josh Poimboeuf wrote: > On Tue, Jan 16, 2018 at 03:28:35PM +0100, Peter Zijlstra wrote: > > When using something like: > > > > -#define sched_feat(x) > > (static_branch_##x(&sched_feat_keys[__SCHED_FEAT_##x])) > > +#define sched_feat(x) > > (static_branch_##x(&sched_feat_keys[__SCHED_FEAT_##x]) && \ > > + (arch_static_assert(), true)) > > > > we get an objtool assertion fail like: > > > > kernel/sched/fair.o: warning: objtool: hrtick_update()+0xd: static assert > > FAIL > > > > where: > > > > 1140 : > > 1140: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > > 1145: c3 retq > > 1146: 48 8b b7 30 09 00 00mov0x930(%rdi),%rsi > > 114d: 8b 87 d8 09 00 00 mov0x9d8(%rdi),%eax > > 1153: 48 0f a3 05 00 00 00bt %rax,0x0(%rip)# 115b > > > > 115a: 00 > > 1157: R_X86_64_PC32 __cpu_active_mask-0x4 > > > > and: > > > > RELOCATION RECORDS FOR [__jump_table]: > > 0150 R_X86_64_64 .text+0x1140 > > 0158 R_X86_64_64 .text+0x1146 > > > > RELOCATION RECORDS FOR [.discard.jump_assert]: > > 0028 R_X86_64_64 .text+0x114d > > > > IOW, GCC managed to place the assertion 1 instruction _after_ the > > static jump target. > > > > So while the code generation is fine, the assertion gets placed wrong. > > We can 'fix' this by not only considering the immediate static jump > > locations but also all the unconditional code after it, terminating > > the basic block on any unconditional instruction or branch entry > > point. > > > > Signed-off-by: Peter Zijlstra (Intel) > > This is pretty similar to something I've been wanting to do, which is to > track all basic blocks. But this is fine enough for now. Right, if we'd have that, we could just mark the entire block as 'static' and be done with it. > One nit, can you rename "branch_target" to "jump_dest" for consistency > with the existing naming? Can't, insn->jump_dest already exists.
Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
>
> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
> support of reporting hints of guest free pages to host via virtio-balloon.
>
> Host requests the guest to report free pages by sending a new cmd
> id to the guest via the free_page_report_cmd_id configuration register.
>
> When the guest starts to report, the first element added to the free page
> vq is the cmd id given by host. When the guest finishes the reporting
> of all the free pages, VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID is added
> to the vq to tell host that the reporting is done. Host may also requests
> the guest to stop the reporting in advance by sending the stop cmd id to
> the guest via the configuration register.
>
> Signed-off-by: Wei Wang
> Signed-off-by: Liang Li
> Cc: Michael S. Tsirkin
> Cc: Michal Hocko
> ---
> drivers/virtio/virtio_balloon.c | 242
> +++-
> include/uapi/linux/virtio_balloon.h | 4 +
> 2 files changed, 214 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c
> b/drivers/virtio/virtio_balloon.c
> index a1fb52c..b9561a5 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -53,7 +53,12 @@ static struct vfsmount *balloon_mnt;
>
> struct virtio_balloon {
> struct virtio_device *vdev;
> - struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> + struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
> +
> + /* Balloon's own wq for cpu-intensive work items */
> + struct workqueue_struct *balloon_wq;
> + /* The free page reporting work item submitted to the balloon wq */
> + struct work_struct report_free_page_work;
>
> /* The balloon servicing is delegated to a freezable workqueue. */
> struct work_struct update_balloon_stats_work;
> @@ -63,6 +68,13 @@ struct virtio_balloon {
> spinlock_t stop_update_lock;
> bool stop_update;
>
> + /* Start to report free pages */
> + bool report_free_page;
> + /* Stores the cmd id given by host to start the free page reporting */
> + uint32_t start_cmd_id;
> + /* Stores STOP_ID as a sign to tell host that the reporting is done */
> + uint32_t stop_cmd_id;
> +
> /* Waiting for host to ack the pages we released. */
> wait_queue_head_t acked;
>
> @@ -281,6 +293,71 @@ static unsigned int update_balloon_stats(struct
> virtio_balloon *vb)
> return idx;
> }
>
> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t
> len)
> +{
> + struct scatterlist sg;
> + unsigned int unused;
> + int err;
> +
> + sg_init_table(&sg, 1);
> + sg_set_page(&sg, pfn_to_page(pfn), len, 0);
> +
> + /* Detach all the used buffers from the vq */
> + while (virtqueue_get_buf(vq, &unused))
> + ;
> +
> + /*
> + * Since this is an optimization feature, losing a couple of free
> + * pages to report isn't important. We simply resturn without adding
> + * the page if the vq is full. We are adding one entry each time,
> + * which essentially results in no memory allocation, so the
> + * GFP_KERNEL flag below can be ignored.
> + */
> + if (vq->num_free) {
> + err = virtqueue_add_inbuf(vq, &sg, 1, vq, GFP_KERNEL);
> + /*
> + * This is expected to never fail, because there is always an
> + * entry available on the vq.
> + */
> + BUG_ON(err);
> + }
> +}
> +
> +static void batch_free_page_sg(struct virtqueue *vq,
> +unsigned long pfn,
> +uint32_t len)
> +{
> + add_one_sg(vq, pfn, len);
> +
> + /* Batch till the vq is full */
> + if (!vq->num_free)
> + virtqueue_kick(vq);
> +}
> +
> +static void send_cmd_id(struct virtqueue *vq, void *addr)
> +{
> + struct scatterlist sg;
> + unsigned int unused;
> + int err;
> +
> + sg_init_one(&sg, addr, sizeof(uint32_t));
> +
> + /*
> + * This handles the cornercase that the vq happens to be full when
> + * adding a cmd id. Rarely happen in practice.
> + */
> + while (!vq->num_free)
> + virtqueue_get_buf(vq, &unused);
> +
> + err = virtqueue_add_outbuf(vq, &sg, 1, vq, GFP_KERNEL);
> + /*
> + * This is expected to never fail, because there is always an
> + * entry available on the vq.
> + */
> + BUG_ON(err);
> + virtqueue_kick(vq);
> +}
> +
> /*
> * While most virtqueues communicate guest-initiated requests to the
> hypervisor,
> * the stats queue operates in reverse. The driver initializes the
> virtqueue
> @@ -316,17 +393,6 @@ static void stats_handle_request(struct virtio_balloon
> *vb)
> virtqueue_kick(vq);
> }
>
> -static void virtballoon_changed(struct virtio_device *vdev)
> -{
> - struct virtio_balloon *vb = vdev->priv;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&
Re: WARNING in can_rcv
On 01/17/2018 08:39 AM, Dmitry Vyukov wrote: On Wed, Jan 17, 2018 at 8:12 AM, Eric Biggers wrote: On Wed, Jan 17, 2018 at 07:39:24AM +0100, Oliver Hartkopp wrote: On 01/16/2018 07:11 PM, Dmitry Vyukov wrote: On Tue, Jan 16, 2018 at 7:07 PM, Marc Kleine-Budde wrote: On 01/16/2018 06:58 PM, syzbot wrote: Hello, syzkaller hit the following crash on a8750ddca918032d6349adbf9a4b6555e7db20da git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. C reproducer is attached syzkaller reproducer is attached. See https://goo.gl/kgGztJ for information about syzkaller reproducers IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+4386709c0c1284dca...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. device eql entered promiscuous mode [ cut here ] PF_CAN: dropped non conform CAN skbuf: dev type 65534, len 42, datalen 0 WARNING: CPU: 0 PID: 3650 at net/can/af_can.c:729 can_rcv+0x1c5/0x200 net/can/af_can.c:724 Kernel panic - not syncing: panic_on_warn set ... Invalid packages generate a warning (WARN_ONCE()), and you have panic_on_warn active. Should we better silently drop these CAN packages? Hi, pr_warn_once() will be more appropriate. It prints a single line. The idea behind this WARN() is to detect really bad things that might have happen on network driver level: The CAN subsystem registers with dev_add_pack() for ETH_P_CAN and ETH_P_CANFD only. These ETH_P_ types are only allowed to be created by CAN network devices (like vcan, vxcan, and real CAN drivers). I don't have any strong opinion on using WARN() or pr_warn_once(). Is this detected violation worth using WARN(), as something already must have gone really wrong to trigger this issue? WARN() indicates a kernel bug. If it's instead "userspace did something stupid", or "someone sent some unexpected network packet", it needs to be pr_warn_once(), pr_warn_ratelimited(), or removed entirely. The packet comes from tun device. We could change tun to filter out such packages earlier. However, in the context of "syzkaller support for AF_CAN" discussion, it would actually be useful for fuzzer to be able emit can packets for testing purposes. Yes - definitely! It's a safer process to check the reception side instead of maintaining thousands of potential transmitters. For example, for tcp it can not just emit random packets, it can build complex user<->network interactions, for example, open a listening socket, connect to it "from outside", accept the connection, and then exchange some data over the active connection. It could do the same for can. Yes. Is it possible to allow can packets via tun? Hm - didn't even think about it. CAN frames have a fixed data structure (struct can_frame) so the tunnel would need to be capable to process SOCK_SEQPACKET (?!?) traffic. Right now there has been no work to 'tunnel' CAN traffic. Then we could leave this WARNING in place. Yes. tun/vcan are contained within a net namespace, so this should not be a security problem, right? vcan can be created in or moved into a namespace. vxcan can bridge namespaces similar to veth. This is all local traffic then. What kind of security problem would you have in mind there? Or is there a way to do the same with vcan? If yes, then fuzzer could use vcan. Yes. This would be my idea too. Unfortunately I'm very busy @work this week - so I would like to dig deeper into your mail some days ago at the beginning of next week. But then we need some fix for this WARNING: either change it to pr_warn or change tun (I don't have strong preference which one). From the discussions (also with Eric) I think going with pr_warn is the right way for now. Tnx & best regards, Oliver
Re: [PATCH 2/5] perf unwind: Do not look at globals
On Tue, Jan 16, 2018 at 05:05:20PM -0300, Arnaldo Carvalho de Melo wrote: SNIP > > > > > > +/* > > > + * Are there any events usind DWARF callchains? > > > + * > > > + * I.e. > > > + * > > > + * -e cycles/call-graph=dwarf/ > > > + */ > > > +bool dwarf_callchain_users; > > > > hum, I don't follow.. this bool seems to mirror the usage of > > 'param->record_mode = CALLCHAIN_DWARF', whats the difference? > > > > also, the patch title says 'Do not look at globals', while inside you > > The first version didn't look at globals, the second one doesn't look at > an _specific_ global variable, the global config for --call-graph, which > is a global variable, callchain_param, which _we_ can't touch at > apply_config_terms(), since that is about _just_ that event, not all of > them. > > > add new global dwarf_callchain_users and work with it.. what do I miss? > > > > I'll check tomorrow with clean head ;-) > > Look closely at apply_config_terms() it passes a _local_ variable to > > perf_evsel__config_callchain(evsel, opts, ¶m); > > It will not affect any globals that tools/perf/util/unwind-libunwind-local.c > could possibly use... and that is the problem. :-) ah ok, that one is local.. just to set up the attrs then adding that new variable is ok, though it could be aded inside struct callchain_param, to keep callchain config stuff together thanks, jirka
Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures
On Tue, Jan 16, 2018 at 3:57 PM, Arnd Bergmann wrote:
> The two functions pass a partially initialized structure back to the
> caller after a memset() on the destination.
>
> This is not entirely well-defined, most compilers are sensible enough
> to either keep the zero-initialization for the uninitialized members,
> but gcc-4.4 does not, and it warns about this:
>
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_sdvo_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_lvds_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used
> uninitialized in this function
>
> This adds an initialization at declaration time to avoid the warning
> and make it well-defined on all compiler versions.
>
> Signed-off-by: Arnd Bergmann
Dave or Daniel, I'm on sick leave and will be for some time to come.
Can one of you pick up this patch? Thanks.
Reviewed-by: Patrik Jakobsson
> ---
> Originally submitted on Sep 15, 2017, but got no reply. Resending unchanged.
> ---
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 0fff269d3fe6..b49fe79c3f44 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -134,7 +134,7 @@ static bool mrst_sdvo_find_best_pll(const struct
> gma_limit_t *limit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t
> *best_clock)
> {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
> u32 target_vco, actual_freq;
> s32 freq_error, min_error = 10;
>
> @@ -191,7 +191,7 @@ static bool mrst_lvds_find_best_pll(const struct
> gma_limit_t *limit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t
> *best_clock)
> {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
> int err = target;
>
> memset(best_clock, 0, sizeof(*best_clock));
> --
> 2.9.0
>
Re: [PATCH v4 2/5] PCI/ERR: Rename error reporting to generic pci naming
On 2018-01-17 06:46, Bjorn Helgaas wrote:
On Tue, Jan 16, 2018 at 03:28:40PM +0530, Oza Pawandeep wrote:
This patch renames error reporting to generic function with pci prefix
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 4fda843..5ed9575 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -285,7 +285,7 @@ static void handle_error_source(struct pcie_device
*aerdev,
pci_write_config_dword(dev, pos + PCI_ERR_COR_STATUS,
info->status);
} else
- do_recovery(dev, info->severity);
+ pci_do_recovery(dev, info->severity);
}
#ifdef CONFIG_ACPI_APEI_PCIEAER
@@ -349,7 +349,7 @@ static void aer_recover_work_func(struct
work_struct *work)
continue;
}
cper_print_aer(pdev, entry.severity, entry.regs);
- do_recovery(pdev, entry.severity);
+ pci_do_recovery(pdev, entry.severity);
pci_dev_put(pdev);
}
}
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index 76e66bb..5792a9f 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -20,12 +20,12 @@
#include
#include "portdrv.h"
-struct aer_broadcast_data {
+struct pci_err_broadcast_data {
enum pci_channel_state state;
enum pci_ers_result result;
};
-pci_ers_result_t merge_result(enum pci_ers_result orig,
+pci_ers_result_t pci_merge_result(enum pci_ers_result orig,
Most of these functions started out static in aerdrv_core.c and should
remain static. Therefore, they do not need to be renamed. Same for
the struct aer_broadcast_data.
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 46fd243..babcd89 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1998,7 +1998,7 @@ static inline resource_size_t
pci_iov_resource_size(struct pci_dev *dev, int res
void pci_hp_remove_module_link(struct pci_slot *pci_slot);
#endif
-void do_recovery(struct pci_dev *dev, int severity);
+void pci_do_recovery(struct pci_dev *dev, int severity);
This one started out static and now needs to be non-static so you can
call it both from aerdrv_core.c and pcie-dpc.c.
But it should not be exposed outside the PCI core, so the declaration
should go in drivers/pci/pcie/aer/aerdrv.h or at most
drivers/pci/pci.h.
The rename should happen before the move out of aerdrv_core.c, i.e.,
reorder patches 1 and 2.
ok so let me confirm. you would like to see renaming but that should
happen right in patch1.
and then move all the error reporting to pcie_err.c
is that correct ?
besides, I am thinking to move
pci_do_recovery and removing everything from include/linux/pci.h (which
you suggested already)
but along with thatfollowing defines will move in driver/pci/pci.h
#define PCI_ERR_AER_NONFATAL 0
#define PCI_ERR_AER_FATAL 1
#define PCI_ERR_AER_CORRECTABLE2
#define PCI_ERR_DPC_NONFATAL 4
because, error codes have to be unified at one place.
will work on this and post the patch-set soon.
Regards,
Oza.
/**
* pci_pcie_cap - get the saved PCIe capability offset
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
Re: [PATCH] [RESEND] drm/gma500: initialize gma_clock_t structures
On Tue, Jan 16, 2018 at 03:57:10PM +0100, Arnd Bergmann wrote:
> The two functions pass a partially initialized structure back to the
> caller after a memset() on the destination.
>
> This is not entirely well-defined, most compilers are sensible enough
> to either keep the zero-initialization for the uninitialized members,
> but gcc-4.4 does not, and it warns about this:
>
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_sdvo_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.vco' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.dot' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.p2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:175: warning: 'clock.m1' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 'mrst_lvds_find_best_pll':
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.vco' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.p2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m2' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.m1' may be used
> uninitialized in this function
> drivers/gpu/drm/gma500/oaktrail_crtc.c:208: warning: 'clock.n' may be used
> uninitialized in this function
>
> This adds an initialization at declaration time to avoid the warning
> and make it well-defined on all compiler versions.
>
> Signed-off-by: Arnd Bergmann
Applied to drm-misc-next-fixes for 4.16, thx for your patch. Aside: Still
don't want commit rights? :-)
Cheers, Daniel
> ---
> Originally submitted on Sep 15, 2017, but got no reply. Resending unchanged.
> ---
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 0fff269d3fe6..b49fe79c3f44 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -134,7 +134,7 @@ static bool mrst_sdvo_find_best_pll(const struct
> gma_limit_t *limit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t *best_clock)
> {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
> u32 target_vco, actual_freq;
> s32 freq_error, min_error = 10;
>
> @@ -191,7 +191,7 @@ static bool mrst_lvds_find_best_pll(const struct
> gma_limit_t *limit,
> struct drm_crtc *crtc, int target,
> int refclk, struct gma_clock_t *best_clock)
> {
> - struct gma_clock_t clock;
> + struct gma_clock_t clock = {};
> int err = target;
>
> memset(best_clock, 0, sizeof(*best_clock));
> --
> 2.9.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: drm: fix vmwgfx boot warning WAS Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps
On 01/17/2018 07:33 AM, Thomas Hellstrom wrote: Hi, Woody, On 01/16/2018 10:39 PM, Woody Suwalski wrote: Thomas, the same way my DRM patch has disappeared: Date Tue, 19 Dec 2017 11:50:57 -0800 From Sinclair Yeh <> Subject Re: [PATCH v.2] 4.15 vmgfx boot warning This looks okay to me. Since this is a core DRM patch I think Sinclair was expecting it to be pulled in using the drm-misc tree. Did you get a comment from Daniel on this patch? Thanks, Thomas Actually, checkpatch.pl complains about -ENOSYS, so I'm sending a pull request for v1 of this patch instead, to make everybody happy. I've rephrased the commit log somewhat. Hope that's OK. /Thomas
Re: [PATCH v2 03/16] pwm: cros-ec: update documentation regarding pwm-cells
On 15.01.2018 11:01, Claudiu Beznea wrote:
>
>
> On 12.01.2018 20:31, Brian Norris wrote:
>> On Fri, Jan 12, 2018 at 04:22:50PM +0200, Claudiu Beznea wrote:
>>> pwm-cells should be at least 2 to provide channel number and period value.
>>
>> Nacked-by: Brian Norris
>>
>> We don't control the period from the kernel; only the duty cycle.
> I agree, I saw this in the driver. This is the way I put the 0x
> period in the patch 7 of this series. I though that since all the drivers
> which uses PWM framework uses the generic PWM bindings (except pwm-pxa.c,
> pwm-cros-ec.c and pwm-clps711x.c) I though it would be simpler (from the
> driver's perspective and also from core's perspective) to have generic
> bindings for all as follows:
> pwms = <&controller PWM-channel PWM-period PWM-flags>;
>
> To allow pwm-cross-ec.c to use this generic binding, since it is uses a
> fix period and of_pwm_xlate() xlate DT arguments without taking care of
> the cross-ec particularity, using 0x period in the pwms binding will
> not harm this driver (correct me if I'm wrong). For this, the pwm-cells
> argument need to be increased at 2. In patch 7 of this series I used
> pwms = <&cros_ec_pwm 1 65535>;
> which initialize the PWM 1 with 0x period.
>
> Thanks,
> Claudiu
>
> (Now,
>> that's perhaps not a wise firmware interface, and we may fix that
>> someday, but you can't just declare a breaking change to a documented,
>> reviewed binding.
>>
>>> Cc: Brian Norris
>>> Signed-off-by: Claudiu Beznea
>>> ---
>>> Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
>>> b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
>>> index 472bd46ab5a4..03347fd302b5 100644
>>> --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
>>> +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
>>> @@ -8,7 +8,7 @@ Documentation/devicetree/bindings/mfd/cros-ec.txt).
>>>
>>> Required properties:
>>> - compatible: Must contain "google,cros-ec-pwm"
>>> -- #pwm-cells: Should be 1. The cell specifies the PWM index.
>>> +- #pwm-cells: Should be 2. The cell specifies the PWM index.
>>
>> Umm, "2 cells", but you use the singular "cell", and don't document what
>> the second one is? That's nonsense.
I didn't saw this comment. The second cell is from the standard PWM binding
as all the other PWM drivers uses. e.g.:
pwms=<&controller PWM-channel PWM-period PWM-flags>
With these changes, if pwm-cells=1 then only PWM-channel will be parsed,
if it is 2 PWM-channel and PWM-period will be parsed, if pwm-cells=3
then PWM-channel, PWM-period and PWM-flags will be parsed.
In your driver you used to have only one cell because you wanted to allow
user to give as argument only PWM channel, and you did not want a change
of PWM period (and in of_xlate function you initialize pwm period with 0x
value: this is why I changed the binding in patch 7 of this series, file
rk3399-gru-kevin.dts). But e.g. sysfs could try to change the PWM period,
there is no restriction to change the PWM period from sysfs, in the sysfs
interface but the restriction is in PWM apply of the drive. The same things
happens with these changes too. The user could introduce any PWM period via
DT but the pwm apply function of the driver will return error.
Thanks,
Claudiu
>>
>> Brian
>>
>>>
>>> Example:
>>> cros-ec@0 {
>>> @@ -18,6 +18,6 @@ Example:
>>>
>>> cros_ec_pwm: ec-pwm {
>>> compatible = "google,cros-ec-pwm";
>>> - #pwm-cells = <1>;
>>> + #pwm-cells = <2>;
>>> };
>>> };
>>> --
>>> 2.7.4
>>>
>>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Re: [PATCH v4 2/5] PCI/ERR: Rename error reporting to generic pci naming
On 2018-01-17 13:54, p...@codeaurora.org wrote:
On 2018-01-17 06:46, Bjorn Helgaas wrote:
On Tue, Jan 16, 2018 at 03:28:40PM +0530, Oza Pawandeep wrote:
This patch renames error reporting to generic function with pci
prefix
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 4fda843..5ed9575 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -285,7 +285,7 @@ static void handle_error_source(struct
pcie_device *aerdev,
pci_write_config_dword(dev, pos + PCI_ERR_COR_STATUS,
info->status);
} else
- do_recovery(dev, info->severity);
+ pci_do_recovery(dev, info->severity);
}
#ifdef CONFIG_ACPI_APEI_PCIEAER
@@ -349,7 +349,7 @@ static void aer_recover_work_func(struct
work_struct *work)
continue;
}
cper_print_aer(pdev, entry.severity, entry.regs);
- do_recovery(pdev, entry.severity);
+ pci_do_recovery(pdev, entry.severity);
pci_dev_put(pdev);
}
}
diff --git a/drivers/pci/pcie/pcie-err.c
b/drivers/pci/pcie/pcie-err.c
index 76e66bb..5792a9f 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -20,12 +20,12 @@
#include
#include "portdrv.h"
-struct aer_broadcast_data {
+struct pci_err_broadcast_data {
enum pci_channel_state state;
enum pci_ers_result result;
};
-pci_ers_result_t merge_result(enum pci_ers_result orig,
+pci_ers_result_t pci_merge_result(enum pci_ers_result orig,
Most of these functions started out static in aerdrv_core.c and should
remain static. Therefore, they do not need to be renamed. Same for
the struct aer_broadcast_data.
ok so in conclusion I should rename only do_recovery. nothing else to be
renamed.
and keep the functions static after moving them to pci_err.c.
Regards,
Oza.
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 46fd243..babcd89 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1998,7 +1998,7 @@ static inline resource_size_t
pci_iov_resource_size(struct pci_dev *dev, int res
void pci_hp_remove_module_link(struct pci_slot *pci_slot);
#endif
-void do_recovery(struct pci_dev *dev, int severity);
+void pci_do_recovery(struct pci_dev *dev, int severity);
This one started out static and now needs to be non-static so you can
call it both from aerdrv_core.c and pcie-dpc.c.
But it should not be exposed outside the PCI core, so the declaration
should go in drivers/pci/pcie/aer/aerdrv.h or at most
drivers/pci/pci.h.
The rename should happen before the move out of aerdrv_core.c, i.e.,
reorder patches 1 and 2.
ok so let me confirm. you would like to see renaming but that should
happen right in patch1.
and then move all the error reporting to pcie_err.c
is that correct ?
besides, I am thinking to move
pci_do_recovery and removing everything from include/linux/pci.h
(which you suggested already)
but along with thatfollowing defines will move in driver/pci/pci.h
#define PCI_ERR_AER_NONFATAL 0
#define PCI_ERR_AER_FATAL 1
#define PCI_ERR_AER_CORRECTABLE2
#define PCI_ERR_DPC_NONFATAL 4
because, error codes have to be unified at one place.
will work on this and post the patch-set soon.
Regards,
Oza.
/**
* pci_pcie_cap - get the saved PCIe capability offset
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
[PATCH 1/4] f2fs: clean up error path of fill_super
This patch cleans up error path of fille_super to avoid unneeded
release step.
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 1a76d229a802..86410875cbb4 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -2607,14 +2607,14 @@ static int f2fs_fill_super(struct super_block *sb, void
*data, int silent)
err = init_percpu_info(sbi);
if (err)
- goto free_options;
+ goto free_bio_info;
if (F2FS_IO_SIZE(sbi) > 1) {
sbi->write_io_dummy =
mempool_create_page_pool(2 * (F2FS_IO_SIZE(sbi) - 1),
0);
if (!sbi->write_io_dummy) {
err = -ENOMEM;
- goto free_options;
+ goto free_percpu;
}
}
@@ -2846,10 +2846,12 @@ static int f2fs_fill_super(struct super_block *sb, void
*data, int silent)
iput(sbi->meta_inode);
free_io_dummy:
mempool_destroy(sbi->write_io_dummy);
-free_options:
+free_percpu:
+ destroy_percpu_info(sbi);
+free_bio_info:
for (i = 0; i < NR_PAGE_TYPE; i++)
kfree(sbi->write_io[i]);
- destroy_percpu_info(sbi);
+free_options:
#ifdef CONFIG_QUOTA
for (i = 0; i < MAXQUOTAS; i++)
kfree(sbi->s_qf_names[i]);
--
2.15.0.55.gc2ece9dc4de6
[PATCH 2/4] f2fs: kill F2FS_INLINE_XATTR_ADDRS for cleanup
Use get_inline_xattr_addrs directly instead of F2FS_INLINE_XATTR_ADDRS.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 2 +-
fs/f2fs/f2fs.h | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 67902ad08d7a..b0e75d74fd57 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1200,7 +1200,7 @@ static int f2fs_xattr_fiemap(struct inode *inode,
phys = (__u64)blk_to_logical(inode, ni.blk_addr);
offset = offsetof(struct f2fs_inode, i_addr) +
sizeof(__le32) * (DEF_ADDRS_PER_INODE -
- F2FS_INLINE_XATTR_ADDRS(inode));
+ get_inline_xattr_addrs(inode));
phys += offset;
len = inline_xattr_size(inode);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index d1bd1ab28f9c..75df68651607 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -416,10 +416,9 @@ struct f2fs_flush_device {
#define DEF_MIN_INLINE_SIZE1
static inline int get_extra_isize(struct inode *inode);
static inline int get_inline_xattr_addrs(struct inode *inode);
-#define F2FS_INLINE_XATTR_ADDRS(inode) get_inline_xattr_addrs(inode)
#define MAX_INLINE_DATA(inode) (sizeof(__le32) * \
(CUR_ADDRS_PER_INODE(inode) - \
- F2FS_INLINE_XATTR_ADDRS(inode) -\
+ get_inline_xattr_addrs(inode) - \
DEF_INLINE_RESERVED_SIZE))
/* for inline dir */
@@ -2330,7 +2329,7 @@ static inline int f2fs_has_inline_xattr(struct inode
*inode)
static inline unsigned int addrs_per_inode(struct inode *inode)
{
- return CUR_ADDRS_PER_INODE(inode) - F2FS_INLINE_XATTR_ADDRS(inode);
+ return CUR_ADDRS_PER_INODE(inode) - get_inline_xattr_addrs(inode);
}
static inline void *inline_xattr_addr(struct inode *inode, struct page *page)
@@ -2338,7 +2337,7 @@ static inline void *inline_xattr_addr(struct inode
*inode, struct page *page)
struct f2fs_inode *ri = F2FS_INODE(page);
return (void *)&(ri->i_addr[DEF_ADDRS_PER_INODE -
- F2FS_INLINE_XATTR_ADDRS(inode)]);
+ get_inline_xattr_addrs(inode)]);
}
static inline int inline_xattr_size(struct inode *inode)
--
2.15.0.55.gc2ece9dc4de6
[PATCH 3/4] f2fs: fix to update last_disk_size correctly
This patch fixes to update last_disk_size only when writing out page
successfully.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index b0e75d74fd57..28c03ea27954 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1716,10 +1716,14 @@ static int __write_data_page(struct page *page, bool
*submitted,
}
}
- down_write(&F2FS_I(inode)->i_sem);
- if (F2FS_I(inode)->last_disk_size < psize)
- F2FS_I(inode)->last_disk_size = psize;
- up_write(&F2FS_I(inode)->i_sem);
+ if (err) {
+ file_set_keep_isize(inode);
+ } else {
+ down_write(&F2FS_I(inode)->i_sem);
+ if (F2FS_I(inode)->last_disk_size < psize)
+ F2FS_I(inode)->last_disk_size = psize;
+ up_write(&F2FS_I(inode)->i_sem);
+ }
done:
if (err && err != -ENOENT)
--
2.15.0.55.gc2ece9dc4de6
[PATCH 4/4] f2fs: split need_inplace_update
This patch splits need_inplace_update to two functions:
a. should_update_inplace() includes all conditions that we must use IPU.
b. should_update_outplace() includes all conditions that we must use OPU.
So that, in f2fs_ioc_set_pin_file() and f2fs_defragment_range(), we can
use corresponding function to check whether we can trigger OPU/IPU or not.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c| 75 +--
fs/f2fs/f2fs.h| 2 ++
fs/f2fs/file.c| 7 +-
fs/f2fs/segment.h | 41 --
4 files changed, 75 insertions(+), 50 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 28c03ea27954..f93ae2d883b9 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1518,20 +1518,79 @@ static int encrypt_one_page(struct f2fs_io_info *fio)
return PTR_ERR(fio->encrypted_page);
}
-static inline bool need_inplace_update(struct f2fs_io_info *fio)
+static inline bool check_inplace_update_policy(struct inode *inode,
+ struct f2fs_io_info *fio)
{
- struct inode *inode = fio->page->mapping->host;
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ unsigned int policy = SM_I(sbi)->ipu_policy;
+ if (policy & (0x1 << F2FS_IPU_FORCE))
+ return true;
+ if (policy & (0x1 << F2FS_IPU_SSR) && need_SSR(sbi))
+ return true;
+ if (policy & (0x1 << F2FS_IPU_UTIL) &&
+ utilization(sbi) > SM_I(sbi)->min_ipu_util)
+ return true;
+ if (policy & (0x1 << F2FS_IPU_SSR_UTIL) && need_SSR(sbi) &&
+ utilization(sbi) > SM_I(sbi)->min_ipu_util)
+ return true;
+
+ /*
+* IPU for rewrite async pages
+*/
+ if (policy & (0x1 << F2FS_IPU_ASYNC) &&
+ fio && fio->op == REQ_OP_WRITE &&
+ !(fio->op_flags & REQ_SYNC) &&
+ !f2fs_encrypted_inode(inode))
+ return true;
+
+ /* this is only set during fdatasync */
+ if (policy & (0x1 << F2FS_IPU_FSYNC) &&
+ is_inode_flag_set(inode, FI_NEED_IPU))
+ return true;
+
+ return false;
+}
+
+bool should_update_inplace(struct inode *inode, struct f2fs_io_info *fio)
+{
if (f2fs_is_pinned_file(inode))
return true;
- if (S_ISDIR(inode->i_mode) || f2fs_is_atomic_file(inode))
- return false;
- if (is_cold_data(fio->page))
- return false;
- if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
+
+ /* if this is cold file, we should overwrite to avoid fragmentation */
+ if (file_is_cold(inode))
+ return true;
+
+ return check_inplace_update_policy(inode, fio);
+}
+
+bool should_update_outplace(struct inode *inode, struct f2fs_io_info *fio)
+{
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+
+ if (test_opt(sbi, LFS))
+ return true;
+ if (S_ISDIR(inode->i_mode))
+ return true;
+ if (f2fs_is_atomic_file(inode))
+ return true;
+ if (fio) {
+ if (is_cold_data(fio->page))
+ return true;
+ if (IS_ATOMIC_WRITTEN_PAGE(fio->page))
+ return true;
+ }
+ return false;
+}
+
+static inline bool need_inplace_update(struct f2fs_io_info *fio)
+{
+ struct inode *inode = fio->page->mapping->host;
+
+ if (should_update_outplace(inode, fio))
return false;
- return need_inplace_update_policy(inode, fio);
+ return should_update_inplace(inode, fio);
}
static inline bool valid_ipu_blkaddr(struct f2fs_io_info *fio)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 75df68651607..5396583b7c85 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2840,6 +2840,8 @@ int f2fs_map_blocks(struct inode *inode, struct
f2fs_map_blocks *map,
int create, int flag);
int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
u64 start, u64 len);
+bool should_update_inplace(struct inode *inode, struct f2fs_io_info *fio);
+bool should_update_outplace(struct inode *inode, struct f2fs_io_info *fio);
void f2fs_set_page_dirty_nobuffers(struct page *page);
int __f2fs_write_data_pages(struct address_space *mapping,
struct writeback_control *wbc,
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f516dea01d0e..9876ad396a7b 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -2081,7 +2081,7 @@ static int f2fs_defragment_range(struct f2fs_sb_info *sbi,
int err;
/* if in-place-update policy is enabled, don't waste time here */
- if (need_inplace_update_policy(inode, NULL))
+ if (should_update_inplace(inode, NULL))
return -EINVAL;
pg_start = range->start >> PAGE_SHIFT;
@@ -2714,6 +2714,11 @@ static int f2f
Re: ipv6 redefinition build issue with 4.15-rc8
On 01/17/2018 08:59 AM, Daniel Wagner wrote: > Hi Neil, > > On 01/16/2018 07:51 PM, Neil MacLeod wrote: >> Since this commit in 4.15-rc8: >> >> https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd >> >> >> building connman 1.35 with glibc 2.26 now fails as follows: >> >> http://ix.io/EbP >> >> I'm not sure if this is a kernel issue, a glibc issue, or a connman >> issue. >> >> Reverting the kernel commit resolves the issue, but isn't ideal >> (unless it's the correct solution, of course). >> >> Does anyone have any better ideas? > > Since ConnMan does not redefine 'struct in6_addr' and friends I would > say it is kernel/glibc header include problem. But I might be wrong here. > > @Hauke: Do you happen to know what is going on? > > Thanks, > Daniel Hi, my assumption is that connman uses a strange include order. Can you try to remove the #include from from include/uapi/linux/if_ether.h please. This would not be the final solution but would help to understand the problem better. I will look into this more closely in the evening. Hauke
Re: [PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings
Hi Sakari,
it's the second series this week where I fail to handle BT.656
properly, sorry about this :)
On Wed, Jan 17, 2018 at 09:59:59AM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Tue, Jan 16, 2018 at 10:44:53PM +0100, Jacopo Mondi wrote:
> > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Rob Herring
> > Reviewed-by: Laurent Pinchart
> > Acked-by: Hans Verkuil
> > ---
> > .../devicetree/bindings/media/renesas,ceu.txt | 81
> > ++
> > 1 file changed, 81 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > new file mode 100644
> > index 000..590ee27
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > @@ -0,0 +1,81 @@
> > +Renesas Capture Engine Unit (CEU)
> > +--
> > +
> > +The Capture Engine Unit is the image capture interface found in the Renesas
> > +SH Mobile and RZ SoCs.
> > +
> > +The interface supports a single parallel input with data bus width of 8 or
> > 16
> > +bits.
> > +
> > +Required properties:
> > +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in
> > RZ/A1-H
> > + and RZ/A1-M SoCs.
> > +- reg: Registers address base and size.
> > +- interrupts: The interrupt specifier.
> > +
> > +The CEU supports a single parallel input and should contain a single 'port'
> > +subnode with a single 'endpoint'. Connection to input devices are modeled
> > +according to the video interfaces OF bindings specified in:
> > +Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +Optional endpoint properties applicable to parallel input bus described in
> > +the above mentioned "video-interfaces.txt" file are supported.
> > +
> > +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
> > respectively.
> > + If property is not present, default is active high.
> > +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
> > respectively.
> > + If property is not present, default is active high.
>
> Does the hardware support Bt.656? If it does, you need to tell the
> difference between the parallel interface with default sync polarity and
> Bt.656 interfaces. With the above it's ambiguous.
No, it does not support BT.656.
I'm listing them as -required- endpoint properties. If they are not
specified the drivers fails during probe:
renesas-ceu e821.ceu: Only parallel input supported.
Thanks
j
>
> > +
> > +Example:
> > +
> > +The example describes the connection between the Capture Engine Unit and an
> > +OV7670 image sensor connected to i2c1 interface.
> > +
> > +ceu: ceu@e821 {
> > + reg = <0xe821 0x209c>;
> > + compatible = "renesas,r7s72100-ceu";
> > + interrupts = ;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vio_pins>;
> > +
> > + status = "okay";
> > +
> > + port {
> > + ceu_in: endpoint {
> > + remote-endpoint = <&ov7670_out>;
> > +
> > + hsync-active = <1>;
> > + vsync-active = <0>;
> > + };
> > + };
> > +};
> > +
> > +i2c1: i2c@fcfee400 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c1_pins>;
> > +
> > + status = "okay";
> > +
> > + clock-frequency = <10>;
> > +
> > + ov7670: camera@21 {
> > + compatible = "ovti,ov7670";
> > + reg = <0x21>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vio_pins>;
> > +
> > + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> > + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> > +
> > + port {
> > + ov7670_out: endpoint {
> > + remote-endpoint = <&ceu_in>;
> > +
> > + hsync-active = <1>;
> > + vsync-active = <0>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.7.4
> >
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi
Re: [PATCH] irqdomain: provide useful debugging information for irq domain
Hi Yang,
On 17/01/18 04:37, Yang Shunyong wrote:
> With recent hashed kernel pointers change, output with %p will
> output hashed address. This patch changes %p to %px in irq domain
> debug information. As unprivileged user has no permission to mount
> debugfs or set printk level to KERN_DEBUG to access the information,
> changes in this patch are appropriate.
>
> Signed-off-by: Yang Shunyong
> ---
> kernel/irq/irqdomain.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 62068ad..d40fbed 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -75,7 +75,7 @@ struct fwnode_handle *__irq_domain_alloc_fwnode(unsigned
> int type, int id,
> n = kasprintf(GFP_KERNEL, "%s-%d", name, id);
> break;
> default:
> - n = kasprintf(GFP_KERNEL, "irqchip@%p", data);
> + n = kasprintf(GFP_KERNEL, "irqchip@%px", data);
> break;
> }
>
> @@ -450,7 +450,7 @@ EXPORT_SYMBOL_GPL(irq_domain_check_msi_remap);
> */
> void irq_set_default_host(struct irq_domain *domain)
> {
> - pr_debug("Default domain set to @0x%p\n", domain);
> + pr_debug("Default domain set to @0x%px\n", domain);
>
> irq_default_domain = domain;
> }
> @@ -635,7 +635,7 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
> struct device_node *of_node;
> int virq;
>
> - pr_debug("irq_create_mapping(0x%p, 0x%lx)\n", domain, hwirq);
> + pr_debug("%s(0x%px, 0x%lx)\n", __func__, domain, hwirq);
>
> /* Look for default domain if nececssary */
> if (domain == NULL)
> @@ -644,7 +644,7 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
> WARN(1, "%s(, %lx) called with NULL domain\n", __func__, hwirq);
> return 0;
> }
> - pr_debug("-> using domain @%p\n", domain);
> + pr_debug("-> using domain @%px\n", domain);
>
> of_node = irq_domain_get_of_node(domain);
>
> @@ -921,7 +921,7 @@ static void virq_debug_show_one(struct seq_file *m,
> struct irq_desc *desc)
> chip = irq_data_get_irq_chip(data);
> seq_printf(m, "%-15s ", (chip && chip->name) ? chip->name :
> "none");
>
> - seq_printf(m, "0x%p ", irq_data_get_irq_chip_data(data));
> + seq_printf(m, "0x%px ", irq_data_get_irq_chip_data(data));
>
> seq_printf(m, " %c", (desc->action &&
> desc->action->handler) ? '*' : ' ');
> direct = (irq == hwirq) && (irq <
> domain->revmap_direct_max_irq);
>
In all honesty, I'd be more inclined to remove this debug feature
altogether, as CONFIG_GENERIC_IRQ_DEBUGFS is more complete and more
useful. Is there any feature missing from that infrastructure that
prevents you from using it instead?
If the answer is "none", then I'll post a patch removing it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [RFC PATCH 5/9] media: vb2: add support for requests
On 01/17/18 09:01, Alexandre Courbot wrote:
> On Tue, Jan 16, 2018 at 7:37 PM, Hans Verkuil wrote:
>> On 01/16/2018 10:39 AM, Alexandre Courbot wrote:
>>> On Mon, Jan 15, 2018 at 6:07 PM, Hans Verkuil wrote:
On 01/15/2018 09:24 AM, Alexandre Courbot wrote:
> On Fri, Jan 12, 2018 at 7:49 PM, Hans Verkuil wrote:
>> On 12/15/17 08:56, Alexandre Courbot wrote:
>>> Add throttling support for buffers when requests are in use on a given
>>> queue. Buffers associated to a request are kept into the vb2 queue until
>>> the request becomes active, at which point all the buffers are passed to
>>> the driver. The queue can also signal that is has processed all of a
>>> request's buffers.
>>>
>>> Also add support for the request parameter when handling the QBUF ioctl.
>>>
>>> Signed-off-by: Alexandre Courbot
>>> ---
>>> drivers/media/v4l2-core/videobuf2-core.c | 59
>>>
>>> drivers/media/v4l2-core/videobuf2-v4l2.c | 29 +++-
>>> include/media/videobuf2-core.h | 25 +-
>>> 3 files changed, 104 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>>> b/drivers/media/v4l2-core/videobuf2-core.c
>>> index cb115ba6a1d2..c01038b7962a 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>>> @@ -898,6 +898,8 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
>>> vb2_buffer_state state)
>>> state != VB2_BUF_STATE_REQUEUEING))
>>> state = VB2_BUF_STATE_ERROR;
>>>
>>> + WARN_ON(vb->request != q->cur_req);
>>
>> What's the reason for this WARN_ON? It's not immediately obvious to me.
>
> This is a safeguard against driver bugs: a buffer should not complete
> unless it is part of the request being currently processed.
>
>>
>>> +
>>> #ifdef CONFIG_VIDEO_ADV_DEBUG
>>> /*
>>>* Although this is not a callback, it still does have to balance
>>> @@ -920,6 +922,13 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
>>> vb2_buffer_state state)
>>> /* Add the buffer to the done buffers list */
>>> list_add_tail(&vb->done_entry, &q->done_list);
>>> vb->state = state;
>>> +
>>> + if (q->cur_req) {
>>> + WARN_ON(q->req_buf_cnt < 1);
>>> +
>>> + if (--q->req_buf_cnt == 0)
>>> + q->cur_req = NULL;
>>> + }
>>> }
>>> atomic_dec(&q->owned_by_drv_count);
>>> spin_unlock_irqrestore(&q->done_lock, flags);
>>> @@ -1298,6 +1307,16 @@ int vb2_core_prepare_buf(struct vb2_queue *q,
>>> unsigned int index, void *pb)
>>> }
>>> EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
>>>
>>> +static void vb2_queue_enqueue_current_buffers(struct vb2_queue *q)
>>> +{
>>> + struct vb2_buffer *vb;
>>> +
>>> + list_for_each_entry(vb, &q->queued_list, queued_entry) {
>>> + if (vb->request == q->cur_req)
>>> + __enqueue_in_driver(vb);
>>> + }
>>> +}
>>
>> I think this will clash big time with the v4l2 fence patch series...
>
> Indeed, but on the other hand I was not a big fan of going through the
> whole list. :) So I welcome the extra throttling introduced by the
> fence series.
There is only throttling if fences are used by userspace. Otherwise there
is no change.
>
>>
>>> +
>>> /**
>>> * vb2_start_streaming() - Attempt to start streaming.
>>> * @q: videobuf2 queue
>>> @@ -1318,8 +1337,7 @@ static int vb2_start_streaming(struct vb2_queue
>>> *q)
>>>* If any buffers were queued before streamon,
>>>* we can now pass them to driver for processing.
>>>*/
>>> - list_for_each_entry(vb, &q->queued_list, queued_entry)
>>> - __enqueue_in_driver(vb);
>>> + vb2_queue_enqueue_current_buffers(q);
>>>
>>> /* Tell the driver to start streaming */
>>> q->start_streaming_called = 1;
>>> @@ -1361,7 +1379,8 @@ static int vb2_start_streaming(struct vb2_queue
>>> *q)
>>> return ret;
>>> }
>>>
>>> -int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
>>> +int vb2_core_qbuf(struct vb2_queue *q, unsigned int index,
>>> + struct media_request *req, void *pb)
>>> {
>>> struct vb2_buffer *vb;
>>> int ret;
>>> @@ -1392,6 +1411,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned
>>> int index, void *pb)
>>> q->queued_count++;
>>> q->waiting_for_buffers = false;
>>> vb->state = VB2_BUF_STATE_QUEUED;
>>
[PATCH] perf test: Fix test trace+probe_libc_inet_pton.sh for s390x
On Intel test case trace+probe_libc_inet_pton.sh succeeds and the
output is:
[root@f27 perf]# ./perf trace --no-syscalls
-e probe_libc:inet_pton/max-stack=3/ ping -6 -c 1 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.037 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms
0.000 probe_libc:inet_pton:(7fa40ac618a0))
__GI___inet_pton (/usr/lib64/libc-2.26.so)
getaddrinfo (/usr/lib64/libc-2.26.so)
main (/usr/bin/ping)
The kernel stack unwinder is used, it is specified implicitly
as call-graph=fp (frame pointer).
On s390x only dwarf is available for stack unwinding. It is also
done in user space. This requires different parameter setup
and result checking for s390x and Intel.
This patch adds separate perf trace setup and result checking
for Intel and s390x. On s390x specify this command line to
get a call-graph and handle the different call graph result
checking:
[root@s35lp76 perf]# ./perf trace --no-syscalls
-e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.041 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.041/0.041/0.041/0.000 ms
0.000 probe_libc:inet_pton:(3ffb9942060))
__GI___inet_pton (/usr/lib64/libc-2.26.so)
gaih_inet (inlined)
__GI_getaddrinfo (inlined)
main (/usr/bin/ping)
__libc_start_main (/usr/lib64/libc-2.26.so)
_start (/usr/bin/ping)
[root@s35lp76 perf]#
Before:
[root@s8360047 perf]# ./perf test -vv 58
58: probe libc's inet_pton & backtrace it with ping :
--- start ---
test child forked, pid 26349
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.079 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.079/0.079/0.079/0.000 ms
0.000 probe_libc:inet_pton:(3ff925c2060))
test child finished with -1
end
probe libc's inet_pton & backtrace it with ping: FAILED!
[root@s8360047 perf]#
After:
[root@s35lp76 perf]# ./perf test -vv 57
57: probe libc's inet_pton & backtrace it with ping :
--- start ---
test child forked, pid 38708
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.038 ms
--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.038/0.038/0.038/0.000 ms
0.000 probe_libc:inet_pton:(3ff87342060))
__GI___inet_pton (/usr/lib64/libc-2.26.so)
gaih_inet (inlined)
__GI_getaddrinfo (inlined)
main (/usr/bin/ping)
__libc_start_main (/usr/lib64/libc-2.26.so)
_start (/usr/bin/ping)
test child finished with 0
end
probe libc's inet_pton & backtrace it with ping: Ok
[root@s35lp76 perf]#
On Intel the test case runs unchanged and succeeds.
Signed-off-by: Thomas Richter
Reviewed-by: Hendrik Brueckner
---
.../perf/tests/shell/trace+probe_libc_inet_pton.sh | 23 +-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
index 8b3da21a08f1..c446c894b297 100755
--- a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
@@ -22,10 +22,23 @@ trace_libc_inet_pton_backtrace() {
expected[4]="rtt min.*"
expected[5]="[0-9]+\.[0-9]+[[:space:]]+probe_libc:inet_pton:\([[:xdigit:]]+\)"
expected[6]=".*inet_pton[[:space:]]\($libc\)$"
- expected[7]="getaddrinfo[[:space:]]\($libc\)$"
- expected[8]=".*\(.*/bin/ping.*\)$"
-
- perf trace --no-syscalls -e probe_libc:inet_pton/max-stack=3/ ping -6
-c 1 ::1 2>&1 | grep -v ^$ | while read line ; do
+ case "$(uname -m)" in
+ s390x)
+ eventattr='call-graph=dwarf'
+ expected[7]="gaih_inet[[:space:]]\(inlined\)$"
+ expected[8]="__GI_getaddrinfo[[:space:]]\(inlined\)$"
+ expected[9]="main[[:space:]]\(.*/bin/ping.*\)$"
+ expected[10]="__libc_start_main[[:space:]]\($libc\)$"
+ expected[11]="_start[[:space:]]\(.*/bin/ping.*\)$"
+ ;;
+ *)
+ eventattr='max-stack=3'
+ expected[7]="getaddrinfo[[:space:]]\($libc\)$"
+ expected[8]=".*\(.*/bin/ping.*\)$"
+ ;;
+ esac
+
+ perf trace --no-syscalls -e probe_libc:inet_pton/$eventattr/ ping -6 -c
1 ::1 2>&1 | grep -v ^$ | while read line ; do
echo $line
echo "$line" | egrep -q "${expected[$idx]}"
if [ $? -ne 0 ] ; then
@@ -33,7 +46,7 @@ trace_libc_inet_pton_backtrace() {
exit 1
fi
let idx+=1
- [ $idx -eq 9
Re: [PATCH] mm/compaction: fix the comment for try_to_compact_pages
On 01/13/2018 12:55 AM, Yang Shi wrote: > "mode" argument is not used by try_to_compact_pages() and sub functions > anymore, it has been replaced by "prio". Fix the comment to explain the > use of "prio" argument. > > Cc: Vlastimil Babka > Cc: Mel Gorman > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Michal Hocko > Signed-off-by: Yang Shi Acked-by: Vlastimil Babka > --- > mm/compaction.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 10cd757..2c8999d 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -1738,7 +1738,7 @@ static enum compact_result compact_zone_order(struct > zone *zone, int order, > * @order: The order of the current allocation > * @alloc_flags: The allocation flags of the current allocation > * @ac: The context of current allocation > - * @mode: The migration mode for async, sync light, or sync migration > + * @prio: Determines how hard direct compaction should try to succeed > * > * This is the main entry point for direct page compaction. > */ >
Re: WARNING in can_rcv
On Wed, Jan 17, 2018 at 9:22 AM, Oliver Hartkopp wrote: > > > On 01/17/2018 08:39 AM, Dmitry Vyukov wrote: >> >> On Wed, Jan 17, 2018 at 8:12 AM, Eric Biggers wrote: >>> >>> On Wed, Jan 17, 2018 at 07:39:24AM +0100, Oliver Hartkopp wrote: On 01/16/2018 07:11 PM, Dmitry Vyukov wrote: > > On Tue, Jan 16, 2018 at 7:07 PM, Marc Kleine-Budde > wrote: >> >> On 01/16/2018 06:58 PM, syzbot wrote: >>> >>> Hello, >>> >>> syzkaller hit the following crash on >>> a8750ddca918032d6349adbf9a4b6555e7db20da >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >>> compiler: gcc (GCC) 7.1.1 20170620 >>> .config is attached >>> Raw console output is attached. >>> C reproducer is attached >>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ >>> for information about syzkaller reproducers >>> >>> >>> IMPORTANT: if you fix the bug, please add the following tag to the >>> commit: >>> Reported-by: syzbot+4386709c0c1284dca...@syzkaller.appspotmail.com >>> It will help syzbot understand when the bug is fixed. See footer for >>> details. >>> If you forward the report, please keep this part and the footer. >>> >>> device eql entered promiscuous mode >>> [ cut here ] >>> PF_CAN: dropped non conform CAN skbuf: dev type 65534, len 42, >>> datalen 0 >>> WARNING: CPU: 0 PID: 3650 at net/can/af_can.c:729 can_rcv+0x1c5/0x200 >>> net/can/af_can.c:724 >>> Kernel panic - not syncing: panic_on_warn set ... >> >> >> Invalid packages generate a warning (WARN_ONCE()), and you have >> panic_on_warn active. Should we better silently drop these CAN >> packages? > > > Hi, > > pr_warn_once() will be more appropriate. It prints a single line. > The idea behind this WARN() is to detect really bad things that might have happen on network driver level: The CAN subsystem registers with dev_add_pack() for ETH_P_CAN and ETH_P_CANFD only. These ETH_P_ types are only allowed to be created by CAN network devices (like vcan, vxcan, and real CAN drivers). I don't have any strong opinion on using WARN() or pr_warn_once(). Is this detected violation worth using WARN(), as something already must have gone really wrong to trigger this issue? >>> >>> WARN() indicates a kernel bug. If it's instead "userspace did something >>> stupid", or "someone sent some unexpected network packet", it needs to be >>> pr_warn_once(), pr_warn_ratelimited(), or removed entirely. >> >> >> >> The packet comes from tun device. We could change tun to filter out >> such packages earlier. However, in the context of "syzkaller support >> for AF_CAN" discussion, it would actually be useful for fuzzer to be >> able emit can packets for testing purposes. > > > Yes - definitely! It's a safer process to check the reception side instead > of maintaining thousands of potential transmitters. > >> For example, for tcp it >> can not just emit random packets, it can build complex user<->network >> interactions, for example, open a listening socket, connect to it >> "from outside", accept the connection, and then exchange some data >> over the active connection. It could do the same for can. > > > Yes. > >> Is it possible to allow can packets via tun? > > > Hm - didn't even think about it. > CAN frames have a fixed data structure (struct can_frame) so the tunnel > would need to be capable to process SOCK_SEQPACKET (?!?) traffic. > > Right now there has been no work to 'tunnel' CAN traffic. But it all seems to be working already (as proven by this report). syzkaller emits ethernet packets with ETH_P_CAN and they are routed to can_rcv. It's just that all packed are dropped on this check. So perhaps if we relax this check, it will all work. >> Then we could leave this >> WARNING in place. > > > Yes. > >> tun/vcan are contained within a net namespace, so >> this should not be a security problem, right? > > > vcan can be created in or moved into a namespace. vxcan can bridge > namespaces similar to veth. This is all local traffic then. > > What kind of security problem would you have in mind there? Something along the following lines: A machine has can network attached and an eithernet cable. Attacker sends ethernet packets with ETH_P_CAN and they are emitted into can stack. The system thinks these packets come from can network, but they actually come from ethernet. But it we allow only tun, then I think it should not be a problem as tun requires admin rights in the net namespace. >> Or is there a way to do the same with vcan? If yes, then fuzzer could >> use vcan. > > > Yes. This would be my idea too. Unfortunately I'm very busy @work this week > - so I would like to dig deeper into your mail some days ago at the > beginning of next week. > >> But then we need some fix for thi
[PATCH v4 5/8] ARM: sun9i: smp: Support CPU/cluster power down and hotplugging for cpu1~7
This patch adds common code used to power down all cores and clusters.
The code was previously based on the MCPM framework. It has now been
adapted to hook into struct smp_operations directly, but the code
structure still shows signs of prior work.
The primary core (cpu0) requires setting flags to have the BROM bounce
execution to the SMP software entry code. This is done in a subsequent
patch to keep the changes cleanly separated. By default the ARM SMP code
blocks cpu0 from being turned off, so splitting this out is safe.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/mc_smp.c | 190 ++-
1 file changed, 189 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index 92e3d7ba496a..fc0acfa07f74 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -30,6 +32,9 @@
#define SUNXI_CPUS_PER_CLUSTER 4
#define SUNXI_NR_CLUSTERS 2
+#define POLL_USEC 100
+#define TIMEOUT_USEC 10
+
#define CPUCFG_CX_CTRL_REG0(c) (0x10 * (c))
#define CPUCFG_CX_CTRL_REG0_L1_RST_DISABLE(n) BIT(n)
#define CPUCFG_CX_CTRL_REG0_L1_RST_DISABLE_ALL 0xf
@@ -37,6 +42,9 @@
#define CPUCFG_CX_CTRL_REG0_L2_RST_DISABLE_A15 BIT(0)
#define CPUCFG_CX_CTRL_REG1(c) (0x10 * (c) + 0x4)
#define CPUCFG_CX_CTRL_REG1_ACINACTM BIT(0)
+#define CPUCFG_CX_STATUS(c)(0x30 + 0x4 * (c))
+#define CPUCFG_CX_STATUS_STANDBYWFI(n) BIT(16 + (n))
+#define CPUCFG_CX_STATUS_STANDBYWFIL2 BIT(0)
#define CPUCFG_CX_RST_CTRL(c) (0x80 + 0x4 * (c))
#define CPUCFG_CX_RST_CTRL_DBG_SOC_RST BIT(24)
#define CPUCFG_CX_RST_CTRL_ETM_RST(n) BIT(20 + (n))
@@ -121,7 +129,7 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned int
cluster)
{
u32 reg;
- pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+ pr_debug("%s: cluster %u cpu %u\n", __func__, cluster, cpu);
if (cpu >= SUNXI_CPUS_PER_CLUSTER || cluster >= SUNXI_NR_CLUSTERS)
return -EINVAL;
@@ -390,8 +398,188 @@ static int sunxi_mc_smp_boot_secondary(unsigned int
l_cpu, struct task_struct *i
return 0;
}
+#ifdef CONFIG_HOTPLUG_CPU
+static void sunxi_cluster_cache_disable(void)
+{
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 1);
+ u32 reg;
+
+ pr_debug("%s: cluster %u\n", __func__, cluster);
+
+ sunxi_cluster_cache_disable_without_axi();
+
+ /* last man standing, assert ACINACTM */
+ reg = readl(cpucfg_base + CPUCFG_CX_CTRL_REG1(cluster));
+ reg |= CPUCFG_CX_CTRL_REG1_ACINACTM;
+ writel(reg, cpucfg_base + CPUCFG_CX_CTRL_REG1(cluster));
+}
+
+static void sunxi_mc_smp_cpu_die(unsigned int l_cpu)
+{
+ unsigned int mpidr, cpu, cluster;
+ bool last_man;
+
+ mpidr = cpu_logical_map(l_cpu);
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ pr_debug("%s: cluster %u cpu %u\n", __func__, cluster, cpu);
+
+ spin_lock(&boot_lock);
+ sunxi_mc_smp_cpu_table[cluster][cpu]--;
+ if (sunxi_mc_smp_cpu_table[cluster][cpu] == 1) {
+ /* A power_up request went ahead of us. */
+ pr_debug("%s: aborting due to a power up request\n",
+__func__);
+ spin_unlock(&boot_lock);
+ return;
+ } else if (sunxi_mc_smp_cpu_table[cluster][cpu] > 1) {
+ pr_err("Cluster %d CPU%d boots multiple times\n",
+ cluster, cpu);
+ BUG();
+ }
+
+ last_man = sunxi_mc_smp_cluster_is_down(cluster);
+ spin_unlock(&boot_lock);
+
+ gic_cpu_if_down(0);
+ if (last_man)
+ sunxi_cluster_cache_disable();
+ else
+ v7_exit_coherency_flush(louis);
+
+ for (;;)
+ wfi();
+}
+
+static int sunxi_cpu_powerdown(unsigned int cpu, unsigned int cluster)
+{
+ u32 reg;
+
+ pr_debug("%s: cluster %u cpu %u\n", __func__, cluster, cpu);
+ if (cpu >= SUNXI_CPUS_PER_CLUSTER || cluster >= SUNXI_NR_CLUSTERS)
+ return -EINVAL;
+
+ /* gate processor power */
+ reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+ reg |= PRCM_PWROFF_GATING_REG_CORE(cpu);
+ writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+ udelay(20);
+
+ /* close power switch */
+ sunxi_cpu_power_switch_set(cpu, cluster, false);
+
+ return 0;
+}
+
+static int sunxi_cluster_powerdown(unsigned int cluster)
+{
+ u32 reg;
+
+ pr_debug("%s: cluster %u\n", __func__, cluster);
+ if (cluster >= SUNXI_NR_CLUSTERS)
+ return -EINVAL;
+
+ /* assert cluster resets or system will hang */
+ pr_debug("%s: assert cluster reset\n", __func__);
+ reg = readl(cpucfg_base + CPUCFG_C
[PATCH v4 7/8] ARM: sun9i: smp: Support cpu0 hotplug
The BROM has a branch that checks if the primary core is hotplugging.
If the magic flag is set, execution jumps to the address set in the
software entry register. (Secondary cores always branch to the that
address.)
This patch sets the flags that makes BROM jump execution on the
primary core (cpu0) to the SMP software entry code when the core is
powered back up. After it is re-integrated into the system, the flag
is cleared.
A custom .cpu_can_disable callback that returns true for all cpus,
so that cpu0 can really be brought down.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/mc_smp.c | 59 +---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
index fc0acfa07f74..11e46c6efb90 100644
--- a/arch/arm/mach-sunxi/mc_smp.c
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -65,8 +65,12 @@
#define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
#define PRCM_CPU_SOFT_ENTRY_REG0x164
+#define CPU0_SUPPORT_HOTPLUG_MAGIC00xFA50392F
+#define CPU0_SUPPORT_HOTPLUG_MAGIC10x790DCA3A
+
static void __iomem *cpucfg_base;
static void __iomem *prcm_base;
+static void __iomem *sram_b_smp_base;
static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
{
@@ -125,6 +129,17 @@ static int sunxi_cpu_power_switch_set(unsigned int cpu,
unsigned int cluster,
return 0;
}
+static void sunxi_cpu0_hotplug_support_set(bool enable)
+{
+ if (enable) {
+ writel(CPU0_SUPPORT_HOTPLUG_MAGIC0, sram_b_smp_base);
+ writel(CPU0_SUPPORT_HOTPLUG_MAGIC1, sram_b_smp_base + 0x4);
+ } else {
+ writel(0x0, sram_b_smp_base);
+ writel(0x0, sram_b_smp_base + 0x4);
+ }
+}
+
static int sunxi_cpu_powerup(unsigned int cpu, unsigned int cluster)
{
u32 reg;
@@ -133,6 +148,10 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned
int cluster)
if (cpu >= SUNXI_CPUS_PER_CLUSTER || cluster >= SUNXI_NR_CLUSTERS)
return -EINVAL;
+ /* Set hotplug support magic flags for cpu0 */
+ if (cluster == 0 && cpu == 0)
+ sunxi_cpu0_hotplug_support_set(true);
+
/* assert processor power-on reset */
reg = readl(prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
reg &= ~PRCM_CPU_PO_RST_CTRL_CORE(cpu);
@@ -362,6 +381,13 @@ static bool sunxi_mc_smp_cluster_is_down(unsigned int
cluster)
return true;
}
+static void sunxi_mc_smp_secondary_init(unsigned int cpu)
+{
+ /* Clear hotplug support magic flags for cpu0 */
+ if (cpu == 0)
+ sunxi_cpu0_hotplug_support_set(false);
+}
+
static int sunxi_mc_smp_boot_secondary(unsigned int l_cpu, struct task_struct
*idle)
{
unsigned int mpidr, cpu, cluster;
@@ -572,13 +598,19 @@ static int sunxi_mc_smp_cpu_kill(unsigned int l_cpu)
return !ret;
}
+static bool sunxi_mc_smp_cpu_can_disable(unsigned int __unused)
+{
+ return true;
+}
#endif
static const struct smp_operations sunxi_mc_smp_smp_ops __initconst = {
+ .smp_secondary_init = sunxi_mc_smp_secondary_init,
.smp_boot_secondary = sunxi_mc_smp_boot_secondary,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_die= sunxi_mc_smp_cpu_die,
.cpu_kill = sunxi_mc_smp_cpu_kill,
+ .cpu_can_disable= sunxi_mc_smp_cpu_can_disable,
#endif
};
@@ -654,7 +686,7 @@ static int __init sunxi_mc_smp_lookback(void)
static int __init sunxi_mc_smp_init(void)
{
- struct device_node *cpucfg_node, *node;
+ struct device_node *cpucfg_node, *sram_node, *node;
struct resource res;
int ret;
@@ -702,16 +734,31 @@ static int __init sunxi_mc_smp_init(void)
goto err_put_cpucfg_node;
}
+ sram_node = of_find_compatible_node(NULL, NULL,
+ "allwinner,sun9i-a80-smp-sram");
+ if (!sram_node) {
+ ret = -ENODEV;
+ goto err_unmap_release_cpucfg;
+ }
+
+ sram_b_smp_base = of_io_request_and_map(sram_node, 0, "sunxi-mc-smp");
+ if (IS_ERR(sram_b_smp_base)) {
+ ret = PTR_ERR(sram_b_smp_base);
+ pr_err("%s: failed to map secure SRAM\n", __func__);
+ goto err_put_sram_node;
+ }
+
/* Configure CCI-400 for boot cluster */
ret = sunxi_mc_smp_lookback();
if (ret) {
pr_err("%s: failed to configure boot cluster: %d\n",
__func__, ret);
- goto err_unmap_release_cpucfg;
+ goto err_unmap_release_secure_sram;
}
- /* We don't need the CPUCFG device node anymore */
+ /* We don't need the CPUCFG and SRAM device nodes anymore */
of_node_put(cpucfg_node);
+ of_node_put(sram_node);
/* Set the hardware entry point address */
writel(__pa_symbol(s
[PATCH v4 6/8] dt-bindings: ARM: sunxi: Document A80 SoC secure SRAM usage by SMP hotplug
On the Allwinner A80 SoC the BROM supports hotplugging the primary core
(cpu0) by checking two 32bit values at a specific location within the
secure SRAM block. This region needs to be reserved and accessible to
the SMP code.
Document its usage.
Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
Reviewed-by: Rob Herring
---
.../devicetree/bindings/arm/sunxi/smp-sram.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
b/Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
new file mode 100644
index ..082e6a9382d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
@@ -0,0 +1,44 @@
+Allwinner SRAM for smp bringup:
+
+
+Allwinner's A80 SoC uses part of the secure sram for hotplugging of the
+primary core (cpu0). Once the core gets powered up it checks if a magic
+value is set at a specific location. If it is then the BROM will jump
+to the software entry address, instead of executing a standard boot.
+
+Therefore a reserved section sub-node has to be added to the mmio-sram
+declaration.
+
+Note that this is separate from the Allwinner SRAM controller found in
+../../sram/sunxi-sram.txt. This SRAM is secure only and not mappable to
+any device.
+
+Also there are no "secure-only" properties. The implementation should
+check if this SRAM is usable first.
+
+Required sub-node properties:
+- compatible : depending on the SoC this should be one of:
+ "allwinner,sun9i-a80-smp-sram"
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+ sram_b: sram@2 {
+ /* 256 KiB secure SRAM at 0x2 */
+ compatible = "mmio-sram";
+ reg = <0x0002 0x4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0002 0x4>;
+
+ smp-sram@1000 {
+ /*
+* This is checked by BROM to determine if
+* cpu0 should jump to SMP entry vector
+*/
+ compatible = "allwinner,sun9i-a80-smp-sram";
+ reg = <0x1000 0x8>;
+ };
+ };
--
2.15.1
[PATCH v4 8/8] ARM: dts: sun9i: Add secure SRAM node used for SMP hotplug
The A80 stores some magic flags in a portion of the secure SRAM. The
BROM jumps directly to the software entry point set by the SMP code
if the flags are set. This is required for CPU0 hotplugging.
Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index bf4d40e8359f..b1c86b76ac3c 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -250,6 +250,25 @@
*/
ranges = <0 0 0 0x2000>;
+ sram_b: sram@2 {
+ /* 256 KiB secure SRAM at 0x2 */
+ compatible = "mmio-sram";
+ reg = <0x0002 0x4>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0002 0x4>;
+
+ smp-sram@1000 {
+ /*
+* This is checked by BROM to determine if
+* cpu0 should jump to SMP entry vector
+*/
+ compatible = "allwinner,sun9i-a80-smp-sram";
+ reg = <0x1000 0x8>;
+ };
+ };
+
ehci0: usb@a0 {
compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
reg = <0x00a0 0x100>;
--
2.15.1
[PATCH v4 4/8] ARM: dts: sun9i: Add PRCM device node for the A80 dtsi
The PRCM is a collection of clock controls, reset controls, and various
power switches/gates. Some of these can be independently listed and
supported, while a number of CPU related ones are used in tandem with
CPUCFG for SMP bringup and CPU hotplugging.
Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 85ecb4d64cfd..bf4d40e8359f 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -709,6 +709,11 @@
interrupts = ;
};
+ prcm@8001400 {
+ compatible = "allwinner,sun9i-a80-prcm";
+ reg = <0x08001400 0x200>;
+ };
+
apbs_rst: reset@80014b0 {
reg = <0x080014b0 0x4>;
compatible = "allwinner,sun6i-a31-clock-reset";
--
2.15.1
[PATCH v4 1/8] ARM: sun9i: Support SMP bring-up on A80
The A80 is a big.LITTLE SoC with 1 cluster of 4 Cortex-A7s and
1 cluster of 4 Cortex-A15s.
This patch adds support to bring up the second cluster and thus all
cores using custom platform SMP code. Core/cluster power down has not
been implemented, thus CPU hotplugging is not supported.
Parts of the trampoline and re-entry code for the boot cpu was adapted
from the MCPM framework.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/Kconfig | 7 +
arch/arm/mach-sunxi/Makefile | 1 +
arch/arm/mach-sunxi/mc_smp.c | 550 +++
3 files changed, 558 insertions(+)
create mode 100644 arch/arm/mach-sunxi/mc_smp.c
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 58153cdf025b..ce53ceaf4cc5 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -48,4 +48,11 @@ config MACH_SUN9I
default ARCH_SUNXI
select ARM_GIC
+config ARCH_SUNXI_MC_SMP
+ bool
+ depends on SMP
+ default MACH_SUN9I
+ select ARM_CCI400_PORT_CTRL
+ select ARM_CPU_SUSPEND
+
endif
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 27b168f121a1..3e741e959c7c 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
+obj-$(CONFIG_ARCH_SUNXI_MC_SMP) += mc_smp.o
obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
new file mode 100644
index ..92e3d7ba496a
--- /dev/null
+++ b/arch/arm/mach-sunxi/mc_smp.c
@@ -0,0 +1,550 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * arch/arm/mach-sunxi/mc_smp.c
+ *
+ * Based on Allwinner code, arch/arm/mach-exynos/mcpm-exynos.c, and
+ * arch/arm/mach-hisi/platmcpm.c
+ * Cluster cache enable trampoline code adapted from MCPM framework
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_CPUS_PER_CLUSTER 4
+#define SUNXI_NR_CLUSTERS 2
+
+#define CPUCFG_CX_CTRL_REG0(c) (0x10 * (c))
+#define CPUCFG_CX_CTRL_REG0_L1_RST_DISABLE(n) BIT(n)
+#define CPUCFG_CX_CTRL_REG0_L1_RST_DISABLE_ALL 0xf
+#define CPUCFG_CX_CTRL_REG0_L2_RST_DISABLE_A7 BIT(4)
+#define CPUCFG_CX_CTRL_REG0_L2_RST_DISABLE_A15 BIT(0)
+#define CPUCFG_CX_CTRL_REG1(c) (0x10 * (c) + 0x4)
+#define CPUCFG_CX_CTRL_REG1_ACINACTM BIT(0)
+#define CPUCFG_CX_RST_CTRL(c) (0x80 + 0x4 * (c))
+#define CPUCFG_CX_RST_CTRL_DBG_SOC_RST BIT(24)
+#define CPUCFG_CX_RST_CTRL_ETM_RST(n) BIT(20 + (n))
+#define CPUCFG_CX_RST_CTRL_ETM_RST_ALL (0xf << 20)
+#define CPUCFG_CX_RST_CTRL_DBG_RST(n) BIT(16 + (n))
+#define CPUCFG_CX_RST_CTRL_DBG_RST_ALL (0xf << 16)
+#define CPUCFG_CX_RST_CTRL_H_RST BIT(12)
+#define CPUCFG_CX_RST_CTRL_L2_RST BIT(8)
+#define CPUCFG_CX_RST_CTRL_CX_RST(n) BIT(4 + (n))
+#define CPUCFG_CX_RST_CTRL_CORE_RST(n) BIT(n)
+
+#define PRCM_CPU_PO_RST_CTRL(c)(0x4 + 0x4 * (c))
+#define PRCM_CPU_PO_RST_CTRL_CORE(n) BIT(n)
+#define PRCM_CPU_PO_RST_CTRL_CORE_ALL 0xf
+#define PRCM_PWROFF_GATING_REG(c) (0x100 + 0x4 * (c))
+#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
+#define PRCM_PWROFF_GATING_REG_CORE(n) BIT(n)
+#define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
+#define PRCM_CPU_SOFT_ENTRY_REG0x164
+
+static void __iomem *cpucfg_base;
+static void __iomem *prcm_base;
+
+static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
+{
+ struct device_node *node;
+ int cpu = cluster * SUNXI_CPUS_PER_CLUSTER + core;
+
+ node = of_cpu_device_node_get(cpu);
+
+ /* In case of_cpu_device_node_get fails */
+ if (!node)
+ node = of_get_cpu_node(cpu, NULL);
+
+ if (!node) {
+ /*
+* There's no point in returning an error, since we
+* would be mid way in a core or cluster power sequence.
+*/
+ pr_err("%s: Couldn't get CPU cluster %u core %u device node\n",
+ __func__, cluster, core);
+
+ return false;
+ }
+
+ return of_device_is_compatible(node, "arm,cortex-a15");
+}
+
+static int sunxi_cpu_power_switch_set(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+ u32 reg;
+
+ /* control sequence from Allwinner A80 user manual v1.2 PRCM section */
+ reg = readl(prcm_base + PRCM_PWR_SWITCH_REG(cluster, cpu));
+ if (enable) {
+ if (reg == 0x00) {
+ pr_debug("power clamp for cluster %u cpu %u already
open\n",
+cluster, cpu);
+ return 0;
+ }
+
+ writel(0xff, prcm_base + PRCM_PWR_SWITCH_REG(cluster, cpu));
+ udela
[PATCH v4 0/8] ARM: sun9i: SMP and CPU hotplug support
This is v4 of my sun9i SMP/hotplug support series which was started over two years ago [1]. We've tried to implement PSCI for both the A80 and A83T. Results were not promising. The issue is that these two chips have a broken security extensions implementation. If a specific bit is not burned in its e-fuse, most if not all security protections don't work [2]. Even worse, non-secure access to the GIC become secure. This requires a crazy workaround in the GIC driver which probably doesn't work in all cases [3]. Version 3 completely did away with the MCPM framework, instead just implementing a set of smp_ops. Most of the code from the previous version was reused, so the structure still has some traces of MCPM. As our hardware has CCI-400, we still need some sort of MMU/cache disabled trampoline code to enable cache coherency. Code for this was adapted from the MCPM framework. This and the entry code are done in inline assembly. Most of the other sunxi-specific code is derived from Allwinner code and documentation, with some references to the other MCPM implementations, as well as the Cortex's Technical Reference Manuals for the power sequencing stuff. In version 4, all traces of MCPM have been removed, except in the comments for atttributing code sources. Thumb2 mode is also fixed. It failed due to an unaligned word access. Hope we can get this version merged. A83T SMP support will be built on it. Regards ChenYu Changes since v3: - Renamed all "MCPM" occurrences to "MC_SMP", as the MCPM framework is no longer used - Thumb2 mode fixed Changes since v2: - Do away with the MCPM framework, directly implement smp_ops - Some debug messages were clarified - New ARCH_SUNXI_MCPM Kconfig symbol for this feature Changes since v1: - Leading zeroes for device node addresses removed - Added device tree binding for SMP SRAM - Simplified Kconfig options - Switched to SPDX license identifier - Map CPU to device tree node and check compatible to see if it's Cortex-A15 or Cortex-A7 - Fix incorrect CPUCFG cluster status macro that prevented cluster 0 L2 cache WFI detection - Fixed reversed bit for turning off cluster - Put cluster in reset before turning off power (or it hangs) - Added dedicated workqueue for turning off power to cpus and clusters - Request CPUCFG and SRAM MMIO ranges - Some comments fixed or added - Some debug messages added [1] http://www.spinics.net/lists/arm-kernel/msg418350.html [2] https://lists.denx.de/pipermail/u-boot/2017-June/294637.html [3] https://github.com/wens/linux/commit/c48654c1f737116e7a7660183c8c74fa91970528 Chen-Yu Tsai (8): ARM: sun9i: Support SMP bring-up on A80 ARM: dts: sun9i: Add CCI-400 device nodes for A80 ARM: dts: sun9i: Add CPUCFG device node for A80 dtsi ARM: dts: sun9i: Add PRCM device node for the A80 dtsi ARM: sun9i: smp: Support CPU/cluster power down and hotplugging for cpu1~7 dt-bindings: ARM: sunxi: Document A80 SoC secure SRAM usage by SMP hotplug ARM: sun9i: smp: Support cpu0 hotplug ARM: dts: sun9i: Add secure SRAM node used for SMP hotplug .../devicetree/bindings/arm/sunxi/smp-sram.txt | 44 ++ arch/arm/boot/dts/sun9i-a80.dtsi | 75 ++ arch/arm/mach-sunxi/Kconfig| 7 + arch/arm/mach-sunxi/Makefile | 1 + arch/arm/mach-sunxi/mc_smp.c | 791 + 5 files changed, 918 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt create mode 100644 arch/arm/mach-sunxi/mc_smp.c -- 2.15.1
[PATCH v4 3/8] ARM: dts: sun9i: Add CPUCFG device node for A80 dtsi
CPUCFG is a collection of registers that are mapped to the SoC's signals
from each individual processor core and associated peripherals, such as
resets for processors, L1/L2 cache and other things.
These registers are used for SMP bringup and CPU hotplugging.
Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 85fb800af8ab..85ecb4d64cfd 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -363,6 +363,11 @@
#reset-cells = <1>;
};
+ cpucfg@170 {
+ compatible = "allwinner,sun9i-a80-cpucfg";
+ reg = <0x0170 0x100>;
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun9i-a80-mmc";
reg = <0x01c0f000 0x1000>;
--
2.15.1
Re: [PATCH v2 12/13] iommu/rockchip: Add runtime PM support
Hi Tomasz, On 01/17/2018 03:52 PM, JeffyChen wrote: Hi Tomasz, On 01/17/2018 03:38 PM, Tomasz Figa wrote: >>Don't we need to check here (and in _shutdown() too) if we have a >>domain attached? > >hmmm, right, the startup might been called by resume, so should check >iommu->domain here. > >but the shutdown would be called at the end of detach or suspend, it could >be not attached or attached. If startup might be called by resume, without domain attached, what prevents shutdown from being called by suspend after that resume, still without domain attached? Is it guaranteed that if resume is called, someone will attach a domain before suspend is called? no, the shutdown would be called by: 1/ end of detach_dev so it would be not attached at that time 2/ suspend so it could be attached, and also could be not attached anyway, i think the shutdown would work without domain attached(just disable paging and clear the iommu bases) ;) hmmm, i see the problem. so we need to: 1/ move shutdown a little earlier in detach_dev, so it could still see the iommu->domain 2/ check iommu->domain in shutdown, to prevent unnecessary shutdown or maybe just add iommu->domain check in suspend and resume. Best regards, Tomasz
[PATCH v4 2/8] ARM: dts: sun9i: Add CCI-400 device nodes for A80
The A80 includes an ARM CCI-400 interconnect to support multi-cluster
CPU caches.
Also add the maximum clock frequency for the CPUs, as listed in the
A80 Optimus Board FEX file.
Signed-off-by: Chen-Yu Tsai
Acked-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80.dtsi | 46
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 90eac0b2a193..85fb800af8ab 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -63,48 +63,64 @@
cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
+ cci-control-port = <&cci_control0>;
+ clock-frequency = <1200>;
reg = <0x0>;
};
cpu1: cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
+ cci-control-port = <&cci_control0>;
+ clock-frequency = <1200>;
reg = <0x1>;
};
cpu2: cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
+ cci-control-port = <&cci_control0>;
+ clock-frequency = <1200>;
reg = <0x2>;
};
cpu3: cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
+ cci-control-port = <&cci_control0>;
+ clock-frequency = <1200>;
reg = <0x3>;
};
cpu4: cpu@100 {
compatible = "arm,cortex-a15";
device_type = "cpu";
+ cci-control-port = <&cci_control1>;
+ clock-frequency = <1800>;
reg = <0x100>;
};
cpu5: cpu@101 {
compatible = "arm,cortex-a15";
device_type = "cpu";
+ cci-control-port = <&cci_control1>;
+ clock-frequency = <1800>;
reg = <0x101>;
};
cpu6: cpu@102 {
compatible = "arm,cortex-a15";
device_type = "cpu";
+ cci-control-port = <&cci_control1>;
+ clock-frequency = <1800>;
reg = <0x102>;
};
cpu7: cpu@103 {
compatible = "arm,cortex-a15";
device_type = "cpu";
+ cci-control-port = <&cci_control1>;
+ clock-frequency = <1800>;
reg = <0x103>;
};
};
@@ -431,6 +447,36 @@
interrupts = ;
};
+ cci: cci@1c9 {
+ compatible = "arm,cci-400";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x01c9 0x1000>;
+ ranges = <0x0 0x01c9 0x1>;
+
+ cci_control0: slave-if@4000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x4000 0x1000>;
+ };
+
+ cci_control1: slave-if@5000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x5000 0x1000>;
+ };
+
+ pmu@9000 {
+compatible = "arm,cci-400-pmu,r1";
+reg = <0x9000 0x5000>;
+interrupts = ,
+ ,
+ ,
+ ,
+ ;
+ };
+ };
+
de_clocks: clock@300 {
compatible = "allwinner,sun9i-a80-de-clks";
reg = <0x0300 0x30>;
--
2.15.1
[PATCH 2/2] Staging: netlogic: platform_net.c: introduced a helper function
In staging/netlogic/platform.c Refactoring the identical code used
in several places for calculating the physical address of
memory-mapped objects on the device.Put that into an inline helper
function and use it.
Adjust the types of arguments of xlr_resource_init() - 'offset' and 'irq'
are actually unsigned. The values passed to those fit into 0..2G range,
so the behaviour is unchanged, but it's more consistent that way.
Signed-off-by: Naveen Panwar
---
drivers/staging/netlogic/platform_net.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/netlogic/platform_net.c
b/drivers/staging/netlogic/platform_net.c
index f45b67a..2196dad 100644
--- a/drivers/staging/netlogic/platform_net.c
+++ b/drivers/staging/netlogic/platform_net.c
@@ -76,11 +76,16 @@ static struct resource xlr_net1_res[8];
static u32 __iomem *gmac4_addr;
static u32 __iomem *gpio_addr;
-static void xlr_resource_init(struct resource *res, int offset, int irq)
+static inline phys_addr_t physaddr(u32 offset)
+{
+ return CPHYSADDR(nlm_mmio_base(offset));
+}
+
+static void xlr_resource_init(struct resource *res, u32 offset, u32 irq)
{
res->name = "gmac";
- res->start = CPHYSADDR(nlm_mmio_base(offset));
+ res->start = physaddr(offset);
res->end = res->start + 0xfff;
res->flags = IORESOURCE_MEM;
@@ -107,8 +112,7 @@ static struct platform_device *gmac_controller2_init(void
*gmac0_addr)
.dev.platform_data = &ndata1,
};
- gmac4_addr = ioremap(CPHYSADDR
- (nlm_mmio_base(NETLOGIC_IO_GMAC_4_OFFSET)), 0xfff);
+ gmac4_addr = ioremap(physaddr(NETLOGIC_IO_GMAC_4_OFFSET), 0xfff);
ndata1.serdes_addr = gmac4_addr;
ndata1.pcs_addr = gmac4_addr;
ndata1.mii_addr = gmac0_addr;
@@ -134,8 +138,7 @@ static void xls_gmac_init(void)
{
int mac;
struct platform_device *xlr_net_dev1;
- void __iomem *gmac0_addr = ioremap(CPHYSADDR
- (nlm_mmio_base(NETLOGIC_IO_GMAC_0_OFFSET)), 0xfff);
+ void __iomem *gmac0_addr = ioremap(physaddr(NETLOGIC_IO_GMAC_0_OFFSET),
0xfff);
static struct xlr_net_data ndata0 = {
.rfr_station= FMN_STNID_GMACRFR_0,
@@ -153,8 +156,7 @@ static void xls_gmac_init(void)
ndata0.mii_addr = gmac0_addr;
/* Passing GPIO base for serdes init. Only needed on sgmii ports */
- gpio_addr = ioremap(CPHYSADDR
- (nlm_mmio_base(NETLOGIC_IO_GPIO_OFFSET)), 0xfff);
+ gpio_addr = ioremap(physaddr(NETLOGIC_IO_GPIO_OFFSET), 0xfff);
ndata0.gpio_addr = gpio_addr;
ndata0.cpu_mask = nlm_current_node()->coremask;
@@ -214,8 +216,7 @@ static void xlr_gmac_init(void)
.id = 0,
.dev.platform_data = &ndata0,
};
- ndata0.mii_addr = ioremap(CPHYSADDR
- (nlm_mmio_base(NETLOGIC_IO_GMAC_0_OFFSET)), 0xfff);
+ ndata0.mii_addr = ioremap(physaddr(NETLOGIC_IO_GMAC_0_OFFSET), 0xfff);
ndata0.cpu_mask = nlm_current_node()->coremask;
--
2.7.4
Re: [PATCH v2 2/2] nvme: add tracepoint for nvme_complete_rq
On Tue, Jan 16, 2018 at 05:50:26PM +0100, Christoph Hellwig wrote: > Just pass the struct request? OK -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH] scsi: ufs: add trace event for ufs upiu
Add UFS Protocol Information Units(upiu) trace events for ufs driver,
used to trace various ufs transaction types- command, task-management
and device management.
The trace-point format is generic and can be easily adapted to trace
other upius if needed.
Currently tracing ufs transaction of type 'device management', which
this patch introduce, cannot be obtained from any other trace.
Device management transactions are used for communication with the
device such as reading and writing descriptor or attributes etc.
Signed-off-by: Ohad Sharabi
---
drivers/scsi/ufs/ufshcd.c | 48 ++
include/trace/events/ufs.h | 28 +++
2 files changed, 76 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..6d79c99 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -274,6 +274,47 @@ static inline void ufshcd_remove_non_printable(char *val)
*val = ' ';
}
+static void ufshcd_add_upiu_trace(struct ufs_hba *hba, unsigned int tag,
+ const char *str)
+{
+ struct utp_task_req_desc *descp;
+ struct utp_upiu_task_req *task_req;
+ struct utp_upiu_req *rq;
+ u8 tx_code, *hdr, *tsf;
+ int off;
+
+ if (!trace_ufshcd_upiu_enabled())
+ return;
+
+ off = (int)tag - hba->nutrs;
+ if (off < 0) {
+ rq = hba->lrb[tag].ucd_req_ptr;
+ hdr = (u8 *)&rq->header;
+ } else {
+ descp = &hba->utmrdl_base_addr[off];
+ task_req = (struct utp_upiu_task_req *)descp->task_req_upiu;
+ hdr = (u8 *)&task_req->header;
+ }
+
+ tx_code = hdr[0] & 0x3f;
+ switch (hdr[0] & 0x3f) {
+ case UPIU_TRANSACTION_COMMAND:
+ tsf = (u8 *)&rq->sc.cdb;
+ break;
+ case UPIU_TRANSACTION_TASK_REQ:
+ tsf = (u8 *)&task_req->input_param1;
+ break;
+ case UPIU_TRANSACTION_QUERY_REQ:
+ tsf = (u8 *)&rq->qr;
+ break;
+ default:
+ return;
+ }
+
+ /* trace UPIU header and Transaction Specific Fields (TSF) */
+ trace_ufshcd_upiu(dev_name(hba->dev), str, hdr, tsf);
+}
+
static void ufshcd_add_command_trace(struct ufs_hba *hba,
unsigned int tag, const char *str)
{
@@ -283,6 +324,9 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp;
int transfer_len = -1;
+ /* trace UPIU also */
+ ufshcd_add_upiu_trace(hba, tag, str);
+
if (!trace_ufshcd_command_enabled())
return;
@@ -5462,11 +5506,14 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba *hba, int
lun_id, int task_id,
spin_unlock_irqrestore(host->host_lock, flags);
+ ufshcd_add_upiu_trace(hba, task_tag, "tm_send");
+
/* wait until the task management command is completed */
err = wait_event_timeout(hba->tm_wq,
test_bit(free_slot, &hba->tm_condition),
msecs_to_jiffies(TM_CMD_TIMEOUT));
if (!err) {
+ ufshcd_add_upiu_trace(hba, task_tag, "tm_complete_err");
dev_err(hba->dev, "%s: task management cmd 0x%.2x timed-out\n",
__func__, tm_function);
if (ufshcd_clear_tm_cmd(hba, free_slot))
@@ -5475,6 +5522,7 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba *hba, int
lun_id, int task_id,
err = -ETIMEDOUT;
} else {
err = ufshcd_task_req_compl(hba, free_slot, tm_response);
+ ufshcd_add_upiu_trace(hba, task_tag, "tm_complete");
}
clear_bit(free_slot, &hba->tm_condition);
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index bf6f826..0b2ff5d 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -257,6 +257,34 @@
)
);
+TRACE_EVENT(ufshcd_upiu,
+ TP_PROTO(const char *dev_name, const char *str, unsigned char *hdr,
+ unsigned char *tsf),
+
+ TP_ARGS(dev_name, str, hdr, tsf),
+
+ TP_STRUCT__entry(
+ __string(dev_name, dev_name)
+ __string(str, str)
+ __array(unsigned char, hdr, 12)
+ __array(unsigned char, tsf, 16)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __assign_str(str, str);
+ memcpy(__entry->hdr, hdr, sizeof(__entry->hdr));
+ memcpy(__entry->tsf, tsf, sizeof(__entry->tsf));
+ ),
+
+ TP_printk(
+ "%s: %s: HDR:%s, CDB:%s",
+ __get_str(str), __get_str(dev_name),
+ __print_hex(__entry->hdr, sizeof(__entry->hdr)),
+ __print_hex(__entry->tsf, sizeof(__entry->tsf))
+ )
+);
+
#endif /* if !defined(_TRACE_UFS_H) || defined(TRACE_HEADER_MULTI_READ) */
/* This part must
Re: [PATCH v6 1/9] dt-bindings: media: Add Renesas CEU bindings
On Wed, Jan 17, 2018 at 09:35:53AM +0100, jacopo mondi wrote:
> Hi Sakari,
> it's the second series this week where I fail to handle BT.656
> properly, sorry about this :)
No worries. I guess I forgot your reply. If the hardware doesn't support
Bt.656 then the current definition is fine.
Acked-by: Sakari Ailus
>
> On Wed, Jan 17, 2018 at 09:59:59AM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Jan 16, 2018 at 10:44:53PM +0100, Jacopo Mondi wrote:
> > > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> > >
> > > Signed-off-by: Jacopo Mondi
> > > Reviewed-by: Rob Herring
> > > Reviewed-by: Laurent Pinchart
> > > Acked-by: Hans Verkuil
> > > ---
> > > .../devicetree/bindings/media/renesas,ceu.txt | 81
> > > ++
> > > 1 file changed, 81 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/media/renesas,ceu.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > > b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > > new file mode 100644
> > > index 000..590ee27
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> > > @@ -0,0 +1,81 @@
> > > +Renesas Capture Engine Unit (CEU)
> > > +--
> > > +
> > > +The Capture Engine Unit is the image capture interface found in the
> > > Renesas
> > > +SH Mobile and RZ SoCs.
> > > +
> > > +The interface supports a single parallel input with data bus width of 8
> > > or 16
> > > +bits.
> > > +
> > > +Required properties:
> > > +- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in
> > > RZ/A1-H
> > > + and RZ/A1-M SoCs.
> > > +- reg: Registers address base and size.
> > > +- interrupts: The interrupt specifier.
> > > +
> > > +The CEU supports a single parallel input and should contain a single
> > > 'port'
> > > +subnode with a single 'endpoint'. Connection to input devices are modeled
> > > +according to the video interfaces OF bindings specified in:
> > > +Documentation/devicetree/bindings/media/video-interfaces.txt
> > > +
> > > +Optional endpoint properties applicable to parallel input bus described
> > > in
> > > +the above mentioned "video-interfaces.txt" file are supported.
> > > +
> > > +- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
> > > respectively.
> > > + If property is not present, default is active high.
> > > +- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
> > > respectively.
> > > + If property is not present, default is active high.
> >
> > Does the hardware support Bt.656? If it does, you need to tell the
> > difference between the parallel interface with default sync polarity and
> > Bt.656 interfaces. With the above it's ambiguous.
>
> No, it does not support BT.656.
>
> I'm listing them as -required- endpoint properties. If they are not
> specified the drivers fails during probe:
>
> renesas-ceu e821.ceu: Only parallel input supported.
>
> Thanks
>j
>
> >
> > > +
> > > +Example:
> > > +
> > > +The example describes the connection between the Capture Engine Unit and
> > > an
> > > +OV7670 image sensor connected to i2c1 interface.
> > > +
> > > +ceu: ceu@e821 {
> > > + reg = <0xe821 0x209c>;
> > > + compatible = "renesas,r7s72100-ceu";
> > > + interrupts = ;
> > > +
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&vio_pins>;
> > > +
> > > + status = "okay";
> > > +
> > > + port {
> > > + ceu_in: endpoint {
> > > + remote-endpoint = <&ov7670_out>;
> > > +
> > > + hsync-active = <1>;
> > > + vsync-active = <0>;
> > > + };
> > > + };
> > > +};
> > > +
> > > +i2c1: i2c@fcfee400 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&i2c1_pins>;
> > > +
> > > + status = "okay";
> > > +
> > > + clock-frequency = <10>;
> > > +
> > > + ov7670: camera@21 {
> > > + compatible = "ovti,ov7670";
> > > + reg = <0x21>;
> > > +
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&vio_pins>;
> > > +
> > > + reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
> > > + powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
> > > +
> > > + port {
> > > + ov7670_out: endpoint {
> > > + remote-endpoint = <&ceu_in>;
> > > +
> > > + hsync-active = <1>;
> > > + vsync-active = <0>;
> > > + };
> > > + };
> > > + };
> > > +};
> > > --
> > > 2.7.4
> > >
> >
> > --
> > Sakari Ailus
> > e-mail: sakari.ai...@iki.fi
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
Re: [PATCH 0/1] Re: kernel BUG at fs/userfaultfd.c:LINE!
Hi! > > Andrea Arcangeli (1): > > userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK > > fails > > > > fs/userfaultfd.c | 20 ++-- > > 1 file changed, 18 insertions(+), 2 deletions(-) > > The original report footer was stripped, so: > > Please credit me with: Reported-by: syzbot Please don't. We don't credit our CPUs, and we don't credit Qemu. We credit humans. > and we also need to tell syzbot about the fix with: > > #syz fix: > userfaultfd: clear the vma->vm_userfaultfd_ctx if UFFD_EVENT_FORK fails Now you claimed you care about bugs being fixed. What about actually testing Andrea's fix and telling us if it fixes the problem or not, and maybe saying "thank you"? Thank you, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v6 03/24] mm: Dont assume page-table invariance during faults
On 17/01/2018 04:04, Andi Kleen wrote: > Laurent Dufour writes: > >> From: Peter Zijlstra >> >> One of the side effects of speculating on faults (without holding >> mmap_sem) is that we can race with free_pgtables() and therefore we >> cannot assume the page-tables will stick around. >> >> Remove the reliance on the pte pointer. > > This needs a lot more explanation. So why is this code not needed with > SPF only? Hi Andi, This is a good question, and I should detail that more in the commit's log. Here is my response to Balbir when he asked for: On 10/07/2017 19:48, Laurent Dufour wrote: > On 07/07/2017 09:07, Balbir Singh wrote: >> On Fri, 2017-06-16 at 19:52 +0200, Laurent Dufour wrote: >>> From: Peter Zijlstra >>> >>> One of the side effects of speculating on faults (without holding >>> mmap_sem) is that we can race with free_pgtables() and therefore we >>> cannot assume the page-tables will stick around. >>> >>> Remove the relyance on the pte pointer. >> ^^ reliance >> >> Looking at the changelog and the code the impact is not clear. >> It looks like after this patch we always assume the pte is not >> the same. What is the impact of this patch? > > Hi Balbir, > > In most of the case pte_unmap_same() was returning 1, which meaning that > do_swap_page() should do its processing. > > So in most of the case there will be no impact. > > Now regarding the case where pte_unmap_safe() was returning 0, and thus > do_swap_page return 0 too, this happens when the page has already been > swapped back. This may happen before do_swap_page() get called or while in > the call to do_swap_page(). In that later case, the check done when > swapin_readahead() returns will detect that case. > > The worst case would be that a page fault is occuring on 2 threads at the > same time on the same swapped out page. In that case one thread will take > much time looping in __read_swap_cache_async(). But in the regular page > fault path, this is even worse since the thread would wait for semaphore to > be released before starting anything. > > Cheers, > Laurent. > I'll add that to the commit's log. Thanks, Laurent.
Re: [PATCH] print kdump kernel loaded status in stack dump
On Wed 2018-01-17 12:50:57, Dave Young wrote:
> It is useful to print kdump kernel loaded status in dump_stack()
> especially when panic happens so that we can differenciate
> kdump kernel early hang and a normal panic in a bug report.
>
> Signed-off-by: Dave Young
> ---
> kernel/printk/printk.c |3 +++
> 1 file changed, 3 insertions(+)
>
> --- linux-x86.orig/kernel/printk/printk.c
> +++ linux-x86/kernel/printk/printk.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -3127,6 +3128,8 @@ void dump_stack_print_info(const char *l
> if (dump_stack_arch_desc_str[0] != '\0')
> printk("%sHardware name: %s\n",
> log_lvl, dump_stack_arch_desc_str);
> + if (kexec_crash_loaded())
> + printk("%skdump kernel loaded\n", log_lvl);
IMHO, it would be better to do it like for the workqueues.
I mean to call printk_kexec_info(log_lv1, current) here
that would be impletemented in kexec sources.
Then it could be maintained by kexec people.
Anyway, I wonder if the info about kexec_crash_loaded() is
enough. I am not much familiar with kexec. AFAIK,
the image might be loaded long time before it
is acutally used.
Finally, the style of the other lines is:
Name: details
I would suggest to print something like:
Kexec: details
, where the details might be whether the image is loaded,
whether the loaded kernel is being executed, and
other kexec-related flags.
How does that sound?
> print_worker_info(log_lvl, current);
> }
Best Regards,
Petr
Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
On 01/17/2018 04:21 PM, Pankaj Gupta wrote:
Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
support of reporting hints of guest free pages to host via virtio-balloon.
Host requests the guest to report free pages by sending a new cmd
id to the guest via the free_page_report_cmd_id configuration register.
When the guest starts to report, the first element added to the free page
vq is the cmd id given by host. When the guest finishes the reporting
of all the free pages, VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID is added
to the vq to tell host that the reporting is done. Host may also requests
the guest to stop the reporting in advance by sending the stop cmd id to
the guest via the configuration register.
Signed-off-by: Wei Wang
Signed-off-by: Liang Li
Cc: Michael S. Tsirkin
Cc: Michal Hocko
---
drivers/virtio/virtio_balloon.c | 242
+++-
include/uapi/linux/virtio_balloon.h | 4 +
2 files changed, 214 insertions(+), 32 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c
b/drivers/virtio/virtio_balloon.c
index a1fb52c..b9561a5 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -53,7 +53,12 @@ static struct vfsmount *balloon_mnt;
struct virtio_balloon {
struct virtio_device *vdev;
- struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+ struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
+
+ /* Balloon's own wq for cpu-intensive work items */
+ struct workqueue_struct *balloon_wq;
+ /* The free page reporting work item submitted to the balloon wq */
+ struct work_struct report_free_page_work;
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
@@ -63,6 +68,13 @@ struct virtio_balloon {
spinlock_t stop_update_lock;
bool stop_update;
+ /* Start to report free pages */
+ bool report_free_page;
+ /* Stores the cmd id given by host to start the free page reporting */
+ uint32_t start_cmd_id;
+ /* Stores STOP_ID as a sign to tell host that the reporting is done */
+ uint32_t stop_cmd_id;
+
/* Waiting for host to ack the pages we released. */
wait_queue_head_t acked;
@@ -281,6 +293,71 @@ static unsigned int update_balloon_stats(struct
virtio_balloon *vb)
return idx;
}
+static void add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t
len)
+{
+ struct scatterlist sg;
+ unsigned int unused;
+ int err;
+
+ sg_init_table(&sg, 1);
+ sg_set_page(&sg, pfn_to_page(pfn), len, 0);
+
+ /* Detach all the used buffers from the vq */
+ while (virtqueue_get_buf(vq, &unused))
+ ;
+
+ /*
+* Since this is an optimization feature, losing a couple of free
+* pages to report isn't important. We simply resturn without adding
+* the page if the vq is full. We are adding one entry each time,
+* which essentially results in no memory allocation, so the
+* GFP_KERNEL flag below can be ignored.
+*/
+ if (vq->num_free) {
+ err = virtqueue_add_inbuf(vq, &sg, 1, vq, GFP_KERNEL);
+ /*
+* This is expected to never fail, because there is always an
+* entry available on the vq.
+*/
+ BUG_ON(err);
+ }
+}
+
+static void batch_free_page_sg(struct virtqueue *vq,
+ unsigned long pfn,
+ uint32_t len)
+{
+ add_one_sg(vq, pfn, len);
+
+ /* Batch till the vq is full */
+ if (!vq->num_free)
+ virtqueue_kick(vq);
+}
+
+static void send_cmd_id(struct virtqueue *vq, void *addr)
+{
+ struct scatterlist sg;
+ unsigned int unused;
+ int err;
+
+ sg_init_one(&sg, addr, sizeof(uint32_t));
+
+ /*
+* This handles the cornercase that the vq happens to be full when
+* adding a cmd id. Rarely happen in practice.
+*/
+ while (!vq->num_free)
+ virtqueue_get_buf(vq, &unused);
+
+ err = virtqueue_add_outbuf(vq, &sg, 1, vq, GFP_KERNEL);
+ /*
+* This is expected to never fail, because there is always an
+* entry available on the vq.
+*/
+ BUG_ON(err);
+ virtqueue_kick(vq);
+}
+
/*
* While most virtqueues communicate guest-initiated requests to the
hypervisor,
* the stats queue operates in reverse. The driver initializes the
virtqueue
@@ -316,17 +393,6 @@ static void stats_handle_request(struct virtio_balloon
*vb)
virtqueue_kick(vq);
}
-static void virtballoon_changed(struct virtio_device *vdev)
-{
- struct virtio_balloon *vb = vdev->priv;
- unsigned long flags;
-
- spin_lock_irqsave(&vb->stop_update_lock, flags);
- if (!vb->stop_update)
- queue_work(syst
Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack
Hi Boris, thanks for testing this :) On Tue, Jan 16, 2018 at 09:47:06PM -0500, Boris Ostrovsky wrote: > On 01/16/2018 11:36 AM, Joerg Roedel wrote: > >+.macro SWITCH_TO_KERNEL_STACK nr_regs=0 check_user=0 > > > This (and next patch's SWITCH_TO_ENTRY_STACK) need X86_FEATURE_PTI check. > > With those macros fixed I was able to boot 32-bit Xen PV guest. Hmm, on bare metal the stack switch happens regardless of the X86_FEATURE_PTI feature being set, because we always program tss.sp0 with the systenter stack. How is the kernel entry stack setup on xen-pv? I think something is missing there instead. Regards, Joerg
Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT
On 17/01/18 02:13, Nicolin Chen wrote:
> On Tue, Jan 16, 2018 at 01:37:46PM -0800, Nicolin Chen wrote:
>> On Tue, Jan 16, 2018 at 09:19:13PM +, Marc Zyngier wrote:
>>
I understand that it should take care of the condition field as
a general instruction handler. Just for curiosity: If we confine
the topic to read access of CNTVCT/CNTFRQ, what'd be the penalty
by ignoring the condition field and executing it anyway?
>>>
>>> Do you mean, apart from severely corrupting userspace execution?
>>> That's a rhetorical question, right?
>>
>> I don't quite understand the corrupting userspace execution part.
>> What I see for a conditional CNTVCT read is more likely:
>> if (condition) {// in this case, if (true)
>> r1 = lower32(cntvct);
>> r2 = higher32(cntvct);
>> }
>>
>> Could you please elaborate a bit? Thank you.
>
> I guess I got it now. The concern seems to be Thumb instructions.
Not only.
> So ignoring a condition for a Thumb instruction may cause its IT
> scope shifting. For ARM mode, the only penalty could be two Rts
> getting written -- which shouldn't corrupt userspace execution.
>
> Please correct me if I am wrong or not thorough.
Consider the following:
mov r0, #0
mov r1, #0
cmp r1, #3
mrrceq r0, r1, cntvct // simplified version
Oh look, you've corrupted r0 and r1, which should never have be changed.
Whatever uses the content r0 and r1 after the mrrc will misbehave. How
is that an acceptable behaviour? How do you expect userspace to cope
with such a brain damage?
If you intend to emulate the CPU, you must emulate it fully, to the
letter of the architecture. No ifs, no buts.
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH] MIPS: use generic GCC library routines from lib/
Hi,
On Wed, Jan 17, 2018 at 09:51:21AM +0300, Antony Pavlov wrote:
> The commit b35cd9884fa5 ("lib: Add shared copies of
> some GCC library routines") makes it possible
> to share generic GCC library routines by several
> architectures.
>
> This commit removes several generic GCC library
> routines from arch/mips/lib/ in favour of similar
> routines from lib/.
>
> Signed-off-by: Antony Pavlov
> Cc: Palmer Dabbelt
> Cc: Ralf Baechle
> Cc: linux-m...@linux-mips.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/mips/Kconfig | 5 +
> arch/mips/lib/Makefile | 2 +-
> arch/mips/lib/ashldi3.c | 30 --
> arch/mips/lib/ashrdi3.c | 32
> arch/mips/lib/cmpdi2.c | 28
> arch/mips/lib/lshrdi3.c | 30 --
> arch/mips/lib/ucmpdi2.c | 22 --
> 7 files changed, 6 insertions(+), 143 deletions(-)
> delete mode 100644 arch/mips/lib/ashldi3.c
> delete mode 100644 arch/mips/lib/ashrdi3.c
> delete mode 100644 arch/mips/lib/cmpdi2.c
> delete mode 100644 arch/mips/lib/lshrdi3.c
> delete mode 100644 arch/mips/lib/ucmpdi2.c
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 350a990fc719..9cd49ee848c6 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -73,6 +73,11 @@ config MIPS
> select RTC_LIB if !MACH_LOONGSON64
> select SYSCTL_EXCEPTION_TRACE
> select VIRT_TO_BUS
> + select GENERIC_ASHLDI3
> + select GENERIC_ASHRDI3
> + select GENERIC_LSHRDI3
> + select GENERIC_CMPDI2
> + select GENERIC_UCMPDI2
Please preserve alphabetical order
>
> menu "Machine selection"
>
> diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
> index 78c2affeabf8..195ab4cb0840 100644
> --- a/arch/mips/lib/Makefile
> +++ b/arch/mips/lib/Makefile
> @@ -16,4 +16,4 @@ obj-$(CONFIG_CPU_R3000) += r3k_dump_tlb.o
> obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o
>
> # libgcc-style stuff needed in the kernel
> -obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o ucmpdi2.o
> +obj-y += bswapsi.o bswapdi.o
> diff --git a/arch/mips/lib/ashldi3.c b/arch/mips/lib/ashldi3.c
> deleted file mode 100644
> index 24cd6903e797..
> --- a/arch/mips/lib/ashldi3.c
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include
> -
> -#include "libgcc.h"
> -
> -long long notrace __ashldi3(long long u, word_type b)
> -{
> - DWunion uu, w;
> - word_type bm;
> -
> - if (b == 0)
> - return u;
> -
> - uu.ll = u;
> - bm = 32 - b;
> -
> - if (bm <= 0) {
> - w.s.low = 0;
> - w.s.high = (unsigned int) uu.s.low << -bm;
> - } else {
> - const unsigned int carries = (unsigned int) uu.s.low >> bm;
> -
> - w.s.low = (unsigned int) uu.s.low << b;
> - w.s.high = ((unsigned int) uu.s.high << b) | carries;
> - }
> -
> - return w.ll;
> -}
> -
> -EXPORT_SYMBOL(__ashldi3);
> diff --git a/arch/mips/lib/ashrdi3.c b/arch/mips/lib/ashrdi3.c
> deleted file mode 100644
> index 23f5295af51e..
> --- a/arch/mips/lib/ashrdi3.c
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include
> -
> -#include "libgcc.h"
> -
> -long long notrace __ashrdi3(long long u, word_type b)
> -{
> - DWunion uu, w;
> - word_type bm;
> -
> - if (b == 0)
> - return u;
> -
> - uu.ll = u;
> - bm = 32 - b;
> -
> - if (bm <= 0) {
> - /* w.s.high = 1..1 or 0..0 */
> - w.s.high =
> - uu.s.high >> 31;
> - w.s.low = uu.s.high >> -bm;
> - } else {
> - const unsigned int carries = (unsigned int) uu.s.high << bm;
> -
> - w.s.high = uu.s.high >> b;
> - w.s.low = ((unsigned int) uu.s.low >> b) | carries;
> - }
> -
> - return w.ll;
> -}
> -
> -EXPORT_SYMBOL(__ashrdi3);
> diff --git a/arch/mips/lib/cmpdi2.c b/arch/mips/lib/cmpdi2.c
> deleted file mode 100644
> index 93cfc785927d..
> --- a/arch/mips/lib/cmpdi2.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include
> -
> -#include "libgcc.h"
> -
> -word_type notrace __cmpdi2(long long a, long long b)
> -{
> - const DWunion au = {
> - .ll = a
> - };
> - const DWunion bu = {
> - .ll = b
> - };
> -
> - if (au.s.high < bu.s.high)
> - return 0;
> - else if (au.s.high > bu.s.high)
> - return 2;
> -
> - if ((unsigned int) au.s.low < (unsigned int) bu.s.low)
> - return 0;
> - else if ((unsigned int) au.s.low > (unsigned int) bu.s.low)
> - return 2;
> -
> - return 1;
> -}
> -
> -EXPORT_SYMBOL(__cmpdi2);
> diff --git a/arch/mips/lib/lshrdi3.c b/arch/mips/lib/lshrdi3.c
> deleted file mode 100644
> index 914b971aca3b..
> --- a/arch/mips/lib/lshrdi3.c
> +++ /dev/null
> @@
Re: [PATCH V4 1/2] nvme: add NVME_CTRL_RESET_PREPARE state
hi Jianchao Wang,
On 1/17/2018 6:54 AM, Jianchao Wang wrote:
Currently, the ctrl->state will be changed to NVME_CTRL_RESETTING
before queue the reset work. This is not so strict. There could be
a big gap before the reset_work callback is invoked. In addition,
there is some disable work in the reset_work callback, strictly
speaking, not part of reset work, and could lead to some confusion.
In addition, after set state to RESETTING and disable procedure,
nvme-rdma/fc use NVME_CTRL_RECONNECTING to mark the setup and
reconnect procedure. The RESETTING state has been narrowed.
This patch add NVME_CTRL_RESET_PREPARE state to mark the reset_work
or error recovery work, scheduling gap and disable procedure.
After that,
- For nvme-pci, nvmet-loop, set state to RESETTING, start
initialization.
- For nvme-rdma, nvme-fc, set state to RECONNECTING, start
initialization or reconnect.
Suggested-by: Christoph Hellwig
Signed-off-by: Jianchao Wang
---
drivers/nvme/host/core.c | 18 +++---
drivers/nvme/host/fc.c | 4 ++--
drivers/nvme/host/nvme.h | 8
drivers/nvme/host/pci.c| 25 +
drivers/nvme/host/rdma.c | 2 +-
drivers/nvme/target/loop.c | 5 +
6 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 230cc09..87d209f 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -87,7 +87,7 @@ static __le32 nvme_get_log_dw10(u8 lid, size_t size)
int nvme_reset_ctrl(struct nvme_ctrl *ctrl)
{
- if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
+ if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESET_PREPARE))
return -EBUSY;
if (!queue_work(nvme_wq, &ctrl->reset_work))
return -EBUSY;
@@ -260,7 +260,7 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
break;
}
break;
- case NVME_CTRL_RESETTING:
+ case NVME_CTRL_RESET_PREPARE:
switch (old_state) {
case NVME_CTRL_NEW:
case NVME_CTRL_LIVE:
@@ -271,10 +271,20 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
break;
}
break;
+
+ case NVME_CTRL_RESETTING:
+ switch (old_state) {
+ case NVME_CTRL_RESET_PREPARE:
+ changed = true;
+ /* FALLTHRU */
+ default:
+ break;
+ }
+ break;
case NVME_CTRL_RECONNECTING:
switch (old_state) {
case NVME_CTRL_LIVE:
- case NVME_CTRL_RESETTING:
+ case NVME_CTRL_RESET_PREPARE:
As I suggested in V3, please don't allow this transition.
We'll move to NVME_CTRL_RECONNECTING from NVME_CTRL_RESETTING.
I look on it like that:
NVME_CTRL_RESET_PREPARE - "suspend" state
NVME_CTRL_RESETTING - "resume" state
you don't reconnect from "suspend" state, you must "resume" before you
reconnect.
changed = true;
/* FALLTHRU */
default:
@@ -286,6 +296,7 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
case NVME_CTRL_LIVE:
case NVME_CTRL_ADMIN_ONLY:
case NVME_CTRL_RESETTING:
+ case NVME_CTRL_RESET_PREPARE:
case NVME_CTRL_RECONNECTING:
changed = true;
/* FALLTHRU */
@@ -2660,6 +2671,7 @@ static ssize_t nvme_sysfs_show_state(struct device *dev,
[NVME_CTRL_LIVE]= "live",
[NVME_CTRL_ADMIN_ONLY] = "only-admin",
[NVME_CTRL_RESETTING] = "resetting",
+ [NVME_CTRL_RESET_PREPARE] = "reset-prepare",
[NVME_CTRL_RECONNECTING]= "reconnecting",
[NVME_CTRL_DELETING]= "deleting",
[NVME_CTRL_DEAD]= "dead",
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index 306aee4..1ba0669 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -546,7 +546,7 @@ nvme_fc_resume_controller(struct nvme_fc_ctrl *ctrl)
queue_delayed_work(nvme_wq, &ctrl->connect_work, 0);
break;
- case NVME_CTRL_RESETTING:
+ case NVME_CTRL_RESET_PREPARE:
/*
* Controller is already in the process of terminating the
* association. No need to do anything further. The reconnect
@@ -789,7 +789,7 @@ nvme_fc_ctrl_connectivity_loss(struct nvme_fc_ctrl *ctrl)
*/
break;
- case NVME_CTRL_RESETTING:
+ case NVME_CTRL_RESET_PREPARE:
/*
* Controller is already in the process of terminating the
* association. No need to do anything further. The reconnect
diff --git a/drivers/nvme/host/nvme.h
Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup
On Tue 2018-01-16 11:44:56, Tejun Heo wrote: > Hello, Steven. > > On Thu, Jan 11, 2018 at 09:55:47PM -0500, Steven Rostedt wrote: > > All I did was start off a work queue on each CPU, and each CPU does one > > printk() followed by a millisecond sleep. No 10,000 printks, nothing > > in an interrupt handler. Preemption is disabled while the printk > > happens, but that's normal. > > > > This is much closer to an OOM happening all over the system, where OOMs > > stack dumps are occurring on different CPUS. > > OOMs can't happen all over the system. It can only happen on a single > CPU at a time. If you're printing from multiple CPUs, your solution > would work great. That is the situation your patches are designed to > address to begin with. That isn't the problem that I reported tho. I > understand that your solution works for that class of problems and > that is great. I really wish that it could address the other class of > problems too tho, and it doesn't seem like it would be that difficult > to cover both cases, right? IMHO, the bad scenario with OOM was that any printk() called in the OOM report became console_lock owner and was responsible for pushing all new messages to the console. There was a possible livelock because OOM Killer was blocked in console_unlock() while other CPUs repeatedly complained about failed allocations. Even the current patch should help. It allows to hand off the console_lock to another CPU and OOM killer could eventually continue. Of course, it is possible that it might not be enough. For example, there might still be too many messages to print when the memory is freed. Therefore there will be no more complains, no more hand offs and the last console_lock owner might still cause softlockup. But it still will be better than the livelockup. Of course, we will need to address the softlockup. But let's see how this works in practice. Best Regards, Petr
Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework
Hi Rafael,
On Mon, Jan 15, 2018 at 5:17 PM, Rafael J. Wysocki wrote:
> On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson wrote:
>> On 15 January 2018 at 14:22, Geert Uytterhoeven wrote:
>
> [cut]
>
>>>
>>> I did miss a small difference in topology: in pm/linux-next, H3 has DMA
>>> enabled for SCIF2, while M3 hasn't (yet).
>>> With DMA enabled on M3, it fails in the same way.
>>>
>>> As genpd_resume_noirq() no longer calls pm_runtime_force_resume(),
>>> rcar_dmac_runtime_resume() is no longer called, and the DMAC's registers
>>> are no longer reinitialized after system resume, breaking the serial port.
>>
>> In drivers/dma/sh/rcar-dmac.c, I would try to replace the below line:
>> SET_SYSTEM_SLEEP_PM_OPS(rcar_dmac_sleep_suspend, rcar_dmac_sleep_resume)
>>
>> with:
>> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
>
> Yes, that probably is the least intrusive thing that can be done to
> address the issue.
>
>> in case that may be too early to suspend the dma device (which is
>> rather common for dma devices) then try;
>>
>> SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>> pm_runtime_force_resume)
>
> Good suggestion, and I would go straight for it anyway.
>
> Geert, can you try if this works, please?
Works. Both using SET_SYSTEM_SLEEP_PM_OPS() and
SET_LATE_SYSTEM_SLEEP_PM_OPS(). But given this is a DMA engine
driver, I'd settle for the latter.
And I did verify doing so doesn't break the system without the patch
in $subject.
Thanks!
Will send a patch...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC] mm: why vfree() do not free page table memory?
On 12/29/2017 09:58 AM, Xishi Qiu wrote: > When calling vfree(), it calls unmap_vmap_area() to clear page table, > but do not free the memory of page table, why? just for performance? I guess it's expected that the free virtual range and associated page tables it might be reused later. > If a driver use vmalloc() and vfree() frequently, we will lost much > page table memory, maybe oom later. If it's reused, then not really. Did you notice an actual issue, or is this just theoretical concern. > Thanks, > Xishi Qiu >
Re: [PATCH] fork: Allow stack to be wiped on fork
On Tue 16-01-18 21:50:15, Kees Cook wrote: > One of the classes of kernel stack content leaks is exposing the contents > of prior heap or stack contents when a new process stack is allocated. > Normally, those stacks are not zeroed, and the old contents remain in > place. With some types of stack content exposure flaws, those contents > can leak to userspace. Kernels built with CONFIG_CLEAR_STACK_FORK will > no longer be vulnerable to this, as the stack will be wiped each time > a stack is assigned to a new process. There's not a meaningful change > in runtime performance; it almost looks like it provides a benefit. Have you tried something as simple as /bin/true in a loop. kbuild will certainly amortize few cycles for the clearing and I would expect, most reasonable applications would do as well. But it would be better to know the worst case scenario IMHO. > Performing back-to-back kernel builds before: > Run times: 157.86 157.09 158.90 160.94 160.80 > Mean: 159.12 > Std Dev: 1.54 > > With CONFIG_CLEAR_STACK_FORK=y: > Run times: 159.31 157.34 156.71 158.15 160.81 > Mean: 158.46 > Std Dev: 1.46 > > Signed-off-by: Kees Cook The change seems reasonable to me. Although it would be better to extend on the types of attacks this prevents from, with some examples ideally. How many attacks of that kind we had in the past and how often they appear. That might help people to decide whether to deserve few cycles on each fork. Also the config option sounds rather limiting. Consider distros, should they enable it just to be on the safe side? This is kind of generic concern with other hardening options though. -- Michal Hocko SUSE Labs
Re: [PATCH] irqdomain: provide useful debugging information for irq domain
On Wed, 17 Jan 2018, Marc Zyngier wrote: > In all honesty, I'd be more inclined to remove this debug feature > altogether, as CONFIG_GENERIC_IRQ_DEBUGFS is more complete and more > useful. Is there any feature missing from that infrastructure that > prevents you from using it instead? > > If the answer is "none", then I'll post a patch removing it. Wanted to do that quite some time ago and never came around to it.
Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack
On Tue, Jan 16, 2018 at 02:45:27PM -0800, Andy Lutomirski wrote: > On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote: > > +.macro SWITCH_TO_KERNEL_STACK nr_regs=0 check_user=0 > > How about marking nr_regs with :req to force everyone to be explicit? Yeah, that's more readable, I'll change it. > > + /* > > +* TSS_sysenter_stack is the offset from the bottom of the > > +* entry-stack > > +*/ > > + movl TSS_sysenter_stack + ((\nr_regs + 1) * 4)(%esp), %esp > > This is incomprehensible. You're adding what appears to be the offset > of sysenter_stack within the TSS to something based on esp and > dereferencing that to get the new esp. That't not actually what > you're doing, but please change asm_offsets.c (as in my previous > email) to avoid putting serious arithmetic in it and then do the > arithmetic right here so that it's possible to follow what's going on. Probably this needs better comments. So TSS_sysenter_stack is the offset from to tss.sp0 (tss.sp1 later) from the _bottom_ of the stack. But in this macro the stack might not be empty, it has a configurable (by \nr_regs) number of dwords on it. Before this instruction we also do a push %edi, so we need (\nr_regs + 1). This can't be put into asm_offset.c, as the actual offset depends on how much is on the stack. > > ENTRY(entry_INT80_32) > > ASM_CLAC > > pushl %eax/* pt_regs->orig_ax */ > > + > > + /* Stack layout: ss, esp, eflags, cs, eip, orig_eax */ > > + SWITCH_TO_KERNEL_STACK nr_regs=6 check_user=1 > > + > > Why check_user? You are right, check_user shouldn't ne needed as INT80 is never called from kernel mode. > > ENTRY(nmi) > > ASM_CLAC > > + > > + /* Stack layout: ss, esp, eflags, cs, eip */ > > + SWITCH_TO_KERNEL_STACK nr_regs=5 check_user=1 > > This is wrong, I think. If you get an nmi in kernel mode but while > still on the sysenter stack, you blow up. IIRC we have some crazy > code already to handle this (for nmi and #DB), and maybe that's > already adequate or can be made adequate, but at the very least this > needs a big comment explaining why it's okay. If we get an nmi while still on the sysenter stack, then we are not entering the handler from user-space and the above code will do nothing and behave as before. But you are right, it might blow up. There is a problem with the cr3 switch, because the nmi can happen in kernel mode before the cr3 is switched, then this handler will not do the cr3 switch itself and crash the kernel. But the stack switching should be fine, I think. > > + /* > > +* TODO: Find a way to let cpu_current_top_of_stack point to > > +* cpu_tss_rw.x86_tss.sp1. Doing so now results in stack corruption > > with > > +* iret exceptions. > > +*/ > > + this_cpu_write(cpu_tss_rw.x86_tss.sp1, next_p->thread.sp0); > > Do you know what the issue is? No, not yet, I will look into that again. But first I want to get this series stable enough as it is. > As a general comment, the interaction between this patch and vm86 is a > bit scary. In vm86 mode, the kernel gets entered with extra stuff on > the stack, which may screw up all your offsets. Just read up on vm86 mode control transfers and the stack layout then. Looks like I need to check for eflags.vm=1 and copy four more registers from/to the entry stack. Thanks for pointing that out. Thanks, Joerg
Re: [PATCH V4 1/2] nvme: add NVME_CTRL_RESET_PREPARE state
Hi Max
Thanks for your kindly response.
I have merged the response to you together below.
On 01/17/2018 05:06 PM, Max Gurtovoy wrote:
>> case NVME_CTRL_RECONNECTING:
>> switch (old_state) {
>> case NVME_CTRL_LIVE:
>> - case NVME_CTRL_RESETTING:
>> + case NVME_CTRL_RESET_PREPARE:
>
> As I suggested in V3, please don't allow this transition.
> We'll move to NVME_CTRL_RECONNECTING from NVME_CTRL_RESETTING.
>
> I look on it like that:
>
> NVME_CTRL_RESET_PREPARE - "suspend" state
> NVME_CTRL_RESETTING - "resume" state
>
> you don't reconnect from "suspend" state, you must "resume" before you
> reconnect.
>> index d49b1e7..6b5f2f4 100644
>> --- a/drivers/nvme/host/rdma.c
>> +++ b/drivers/nvme/host/rdma.c
>> @@ -985,7 +985,7 @@ static void nvme_rdma_error_recovery_work(struct
>> work_struct *work)
>> static void nvme_rdma_error_recovery(struct nvme_rdma_ctrl *ctrl)
>> {
>> - if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESETTING))
>> + if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESET_PREPARE))
>> return;
>
> We can add a NVME_CTRL_RESET_PREPARE --> NVME_CTRL_RESETTING transition and
> then move to NVME_CTRL_RECONNECTING (in nvme_rdma_reset_ctrl_work and
> nvme_rdma_error_recovery_work).
> I want to add an ability to recover from device removal (actually wanted to
> send it today but I'm waiting to see what will happen with this patchset) for
> RDMA and your approach (enable transition to from both "suspend" and "resume"
> to "reconnect") might be problematic.
>
> Sagi/Christoph ?
I used to respond you in the V3 and wait for your feedback.
Please refer to:
>>>
After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl state
is changed to RECONNECTING state
after some clearing and shutdown work, then some initializing procedure, no
matter reset work path or error recovery path.
The fc reset work also does the same thing.
So if we define the range that RESET_PREPARE includes scheduling gap and
disable and clear work, RESETTING includes initializing
procedure, RECONNECTING is very similar with RESETTING.
Maybe we could do like this;
In nvme fc/rdma
- set state to RESET_PREPARE, queue reset_work/err_work
- clear/shutdown works, set state to RECONNECTING
- initialization, set state to LIVE
In nvme pci
- set state to RESET_PREPARE, queue reset_work
- clear/shutdown works, set state to RESETTING
- initialization, set state to LIVE
>>>
Currently, RECONNECTING has overlapped with RESETTING.
So I suggest to use RESET_PREPARE to mark the "suspend" part as you said.
And use RECONNECTING to mark the "resume" part in nvme-rdma/fc
use RESETTING part to mark the "resume" part in nvme-pci, nvmt-loop.
I want to confirm with all of you, but no none had feedback, so I sent out the
patch directly.
Please forgive my abrupt actions.
Thanks
Jianchao
Thanks
Jianchao
Re: [PATCH v2 06/10] objtool: Implement jump_assert for _static_cpu_has()
On Tue, Jan 16, 2018 at 05:02:56PM -0600, Josh Poimboeuf wrote:
> On Tue, Jan 16, 2018 at 03:28:31PM +0100, Peter Zijlstra wrote:
> > + if (special_alt->static_feat)
>
> s/static_feat/static_cpu_has/ ?
done.
> > @@ -664,6 +670,21 @@ static int handle_group_alt(struct objto
> > insn->sec, insn->offset);
> > return -1;
> > }
> > +
> > + if (special_alt->static_feat) {
> > + if (insn->type != INSN_JUMP_UNCONDITIONAL) {
> > + WARN_FUNC("not an unconditional jump in
> > _static_cpu_has()",
> > + insn->sec, insn->offset);
> > + }
>
> So I think this is trying to assert the fact that you're only expecting
> a single instruction which is an unconditional jump.
Correct.
> We already weeded
> out non-jumps earlier in the loop, so would it make sense to do this
> check before the INSN_JUMP_CONDITIONAL/INSN_JUMP_UNCONDITIONAL check a
> little higher up?
This way we keep all the special_alt->static_cpu_has bits together.
> > + if (insn->jump_dest == fake_jump) {
> > + WARN_FUNC("jump inside alternative for
> > _static_cpu_has()",
> > + insn->sec, insn->offset);
> > + }
>
> The error message doesn't seem to match the condition, so I'm not sure
> which one you're trying to check, or why.
>
> IIRC, 'insn->jump_dest == fake_jump' means we reached the end of the
> alternative code block without hitting a jump.
>
> But based on the loop exit condition, I don't think it's ever possible
> for insn->jump_dest to ever point to the fake_jump at the end.
Oof, now what was I thinking again.. So that fake_jump is inserted at
the end of the alternative and jumps to the code after where the
alternative will be patched in to simulate the code flow.
If there is a jump inside the alternative that jumps to the end, it's
destination will be set to the fake jump, we have this clause for that:
dest_off = insn->offset + insn->len + insn->immediate;
if (dest_off == special_alt->new_off + special_alt->new_len)
insn->jump_dest = fake_jump;
if that happens for static_cpu_has(), bad things happened.
So the only way for a jump to have fake_jump as destination is if the
jump is inside the alternative (but to the end) and we must assert this
didn't happen.
Unlikely, yes, but I figured we want to know about it if it ever does
happen.
> > --- a/tools/objtool/special.c
> > +++ b/tools/objtool/special.c
> > @@ -40,6 +40,11 @@
> > #define ALT_FEATURE_OFFSET 8
> > #define ALT_ORIG_LEN_OFFSET10
> > #define ALT_NEW_LEN_OFFSET 11
> > +#define ALT_PADDING_OFFSET 12
> > +#define ALT_TYPE_OFFSET13
>
> We don't need the ALT_PADDING_OFFSET define (notice we have gaps
> already, there are only defines for the ones we use).
Over zealous I suppose, I've taken it out again.
> > +
> > +#define ALT_TYPE_DEFAULT 0
> > +#define ALT_TYPE_STATIC_CPU_HAS1
> >
> > #define X86_FEATURE_POPCNT (4*32+23)
> >
> > @@ -99,10 +104,13 @@ static int get_alt_entry(struct elf *elf
> >
> > if (entry->feature) {
>
> Since this block now uses more than entry->feature, and is now just a
> general alternatives thing, can you change it to
>
> if (entry->feature == ALT_FEATURE_OFFSET)
>
> so it's more clear and slightly more future proof?
I've made it entry->group instead. How about the below on top?
---
Subject: objtool: Introduce special_type
From: Peter Zijlstra
Date: Wed Jan 17 10:16:44 CET 2018
Use an enum for the special_alt entries instead of a collection of
booleans.
Signed-off-by: Peter Zijlstra (Intel)
---
tools/objtool/check.c | 11 ---
tools/objtool/special.c | 21 +
tools/objtool/special.h | 10 --
3 files changed, 25 insertions(+), 17 deletions(-)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -773,7 +773,7 @@ static int add_special_section_alts(stru
continue;
new_insn = NULL;
- if (!special_alt->group || special_alt->new_len) {
+ if (special_alt->type != alternative || special_alt->new_len) {
new_insn = find_insn(file, special_alt->new_sec,
special_alt->new_off);
if (!new_insn) {
@@ -785,16 +785,21 @@ static int add_special_section_alts(stru
}
}
- if (special_alt->group) {
+ switch(special_alt->type) {
+ case alternative:
ret = handle_group_alt(file, special_alt, orig_insn,
&new_insn);
if (ret)
goto out;
- }
Re: [PATCH 06/19] drm/blend: Add a generic alpha property
On Thu, Jan 11, 2018 at 08:34:58PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote: > > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > > > Some drivers duplicate the logic to create a property to store a > > > per-plane alpha. > > > > > > Let's create a helper in order to move that to the core. > > > > > > Cc: Boris Brezillon > > > Cc: Laurent Pinchart > > > Signed-off-by: Maxime Ripard > > > > Do we have userspace for this? > > >>> > > >>> Wayland seems to be on its way to implement this, with ChromeOS using > > >>> it: > > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741 > > >>> .html > > >>> > > >>> and more specifically: > > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way > > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1 > > >>> .xml#118 > > >> > > >> Yay, would be good to include these links in the patch description. > > >> Really happy we're having a real standard now used by multiple people. > > > > > > I will. > > > > > >> > > Is encoding a fixed 0-255 range really the best idea? > > >> > > > >> > I don't really know, is there hardware or formats where there is more > > >> > than 255? Or did you mean less than that? > > >> > > >> 30bit I'd assume wants more alpha. In the past we've done some > > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using > > >> that for the blend equation docs is also what I recommend (and that we > > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that > > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's > > >> what we're doing for gamma tables already, and that way drivers can > > >> simply throw away the lower bits. > > > > > > But that would also break the two users of that property that won't be > > > able to move to the generic property (with the same name) without > > > breaking userspace. The point of that patch was to allow some code > > > consolidation, and that would mean failing to do so here :/ > > > > Let me try to clarify: > > - We'll keep the exact existing property semantics with the 0-255 > > range for the userspace visible property. > > > > - But internally, in the decode value that we store into > > drm_plane_state, we'll do the slightly more future proof thing with a > > few more bits. > > > > That gives us the option of exposing those bits in the future without > > having to change all the drivers again (which we have to do for this > > series here already anyway, since the decoded value moves into > > drm_plane_state from driver subclasses). > > > > Definitely not asking to break userspace here :-) > > As the property range is available to userspace, we could allow drivers to > expose a driver-dependent number of bits for the alpha value without breaking > anything. We can even require new drivers to expose 16 bits regardless of the > number of bits that the hardware can handle, or we could keep that driver- > specific. > > Please note, however, that U0.16 can only represent [0.0, 0.84741...] > while we need [0.0, 1.0]. As all the hardware I know map the full range of > values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend > that > the 16-bit value exposed to userspace is U0.16. So this would involve not changing too much the current patch, but instead extending the type from an u8 to an u16. Would that work for you Daniel? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH v2 5/5] powerpc/mm: Remove intermediate bitmap copy in 'slices'
bitmap_or() and bitmap_andnot() can work properly with dst identical
to src1 or src2. There is no need of an intermediate result bitmap
that is copied back to dst in a second step.
Signed-off-by: Christophe Leroy
---
v2: New in v2
arch/powerpc/mm/slice.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index fa6f7f63223c..9d88b1c03caa 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -72,8 +72,6 @@ static void slice_print_mask(const char *label, struct
slice_mask mask) {}
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
-#define slice_bitmap_copy(dst, src, nbits) \
- do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
@@ -416,25 +414,18 @@ static unsigned long slice_find_area(struct mm_struct
*mm, unsigned long len,
static inline void slice_or_mask(struct slice_mask *dst, struct slice_mask
*src)
{
- DECLARE_BITMAP(result, SLICE_NUM_HIGH);
-
slice_bitmap_or(dst->low_slices, dst->low_slices, src->low_slices,
SLICE_NUM_LOW);
- slice_bitmap_or(result, dst->high_slices, src->high_slices,
+ slice_bitmap_or(dst->high_slices, dst->high_slices, src->high_slices,
SLICE_NUM_HIGH);
- slice_bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
}
static inline void slice_andnot_mask(struct slice_mask *dst, struct slice_mask
*src)
{
- DECLARE_BITMAP(result, SLICE_NUM_HIGH);
-
slice_bitmap_andnot(dst->low_slices, dst->low_slices, src->low_slices,
SLICE_NUM_LOW);
-
- slice_bitmap_andnot(result, dst->high_slices, src->high_slices,
- SLICE_NUM_HIGH);
- slice_bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
+ slice_bitmap_andnot(dst->high_slices, dst->high_slices,
+ src->high_slices, SLICE_NUM_HIGH);
}
#ifdef CONFIG_PPC_64K_PAGES
--
2.13.3
[PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32
In preparation for the following patch which will fix an issue on the 8xx by re-using the 'slices', this patch enhances the 'slices' implementation to support 32 bits CPUs. On PPC32, the address space is limited to 4Gbytes, hence only the low slices will be used. As of today, the code uses SLICE_LOW_TOP (0x1ul) and compares it with addr to determine if addr refers to low or high space. On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because 0x1ul degrades to 0. Therefore, the patch modifies SLICE_LOW_TOP to (0xul) and modifies the tests to (addr <= SLICE_LOW_TOP) which will then always be true on PPC32 as addr has type 'unsigned long' while not modifying the PPC64 behaviour. This patch moves "slices" functions prototypes from page64.h to page.h The high slices use bitmaps. As bitmap functions are not prepared to handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into slice_bitmap_xxx() macros which will take care of the 0 nbits case. Signed-off-by: Christophe Leroy --- v2: First patch of v1 serie split in two parts ; added slice_bitmap_xxx() macros. arch/powerpc/include/asm/page.h | 14 + arch/powerpc/include/asm/page_32.h | 19 arch/powerpc/include/asm/page_64.h | 21 ++--- arch/powerpc/mm/hash_utils_64.c | 2 +- arch/powerpc/mm/mmu_context_nohash.c | 7 + arch/powerpc/mm/slice.c | 60 6 files changed, 83 insertions(+), 40 deletions(-) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index 8da5d4c1cab2..d0384f9db9eb 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -342,6 +342,20 @@ typedef struct page *pgtable_t; #endif #endif +#ifdef CONFIG_PPC_MM_SLICES +struct mm_struct; + +unsigned long slice_get_unmapped_area(unsigned long addr, unsigned long len, + unsigned long flags, unsigned int psize, + int topdown); + +unsigned int get_slice_psize(struct mm_struct *mm, unsigned long addr); + +void slice_set_user_psize(struct mm_struct *mm, unsigned int psize); +void slice_set_range_psize(struct mm_struct *mm, unsigned long start, + unsigned long len, unsigned int psize); +#endif + #include #endif /* __ASSEMBLY__ */ diff --git a/arch/powerpc/include/asm/page_32.h b/arch/powerpc/include/asm/page_32.h index 5c378e9b78c8..f7d1bd1183c8 100644 --- a/arch/powerpc/include/asm/page_32.h +++ b/arch/powerpc/include/asm/page_32.h @@ -60,4 +60,23 @@ extern void copy_page(void *to, void *from); #endif /* __ASSEMBLY__ */ +#ifdef CONFIG_PPC_MM_SLICES + +#define SLICE_LOW_SHIFT28 +#define SLICE_HIGH_SHIFT 0 + +#define SLICE_LOW_TOP (0xul) +#define SLICE_NUM_LOW ((SLICE_LOW_TOP >> SLICE_LOW_SHIFT) + 1) +#define SLICE_NUM_HIGH 0ul + +#define GET_LOW_SLICE_INDEX(addr) ((addr) >> SLICE_LOW_SHIFT) +#define GET_HIGH_SLICE_INDEX(addr) (addr & 0) + +#ifdef CONFIG_HUGETLB_PAGE +#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA +#endif +#define HAVE_ARCH_UNMAPPED_AREA +#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN + +#endif #endif /* _ASM_POWERPC_PAGE_32_H */ diff --git a/arch/powerpc/include/asm/page_64.h b/arch/powerpc/include/asm/page_64.h index 56234c6fcd61..a7baef5bbe5f 100644 --- a/arch/powerpc/include/asm/page_64.h +++ b/arch/powerpc/include/asm/page_64.h @@ -91,30 +91,13 @@ extern u64 ppc64_pft_size; #define SLICE_LOW_SHIFT28 #define SLICE_HIGH_SHIFT 40 -#define SLICE_LOW_TOP (0x1ul) -#define SLICE_NUM_LOW (SLICE_LOW_TOP >> SLICE_LOW_SHIFT) +#define SLICE_LOW_TOP (0xul) +#define SLICE_NUM_LOW ((SLICE_LOW_TOP >> SLICE_LOW_SHIFT) + 1) #define SLICE_NUM_HIGH (H_PGTABLE_RANGE >> SLICE_HIGH_SHIFT) #define GET_LOW_SLICE_INDEX(addr) ((addr) >> SLICE_LOW_SHIFT) #define GET_HIGH_SLICE_INDEX(addr) ((addr) >> SLICE_HIGH_SHIFT) -#ifndef __ASSEMBLY__ -struct mm_struct; - -extern unsigned long slice_get_unmapped_area(unsigned long addr, -unsigned long len, -unsigned long flags, -unsigned int psize, -int topdown); - -extern unsigned int get_slice_psize(struct mm_struct *mm, - unsigned long addr); - -extern void slice_set_user_psize(struct mm_struct *mm, unsigned int psize); -extern void slice_set_range_psize(struct mm_struct *mm, unsigned long start, - unsigned long len, unsigned int psize); - -#endif /* __ASSEMBLY__ */ #else #define slice_init() #ifdef CONFIG_PPC_BOOK3S_64 diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 655a5a9a183d..3266b3326088 100644 --- a/arch/powerpc/mm/hash_utils_
[PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address
On the 8xx, the page size is set in the PMD entry and applies to
all pages of the page table pointed by the said PMD entry.
When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the hint allthough the 8xx cannot handle different
page sizes in the same PMD entry.
1000-10001000 r-xp 00:0f 2597 /root/malloc
1001-10011000 rwxp 00:0f 2597 /root/malloc
mmap(0x1008, 524288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) = 0x1008
This results the app remaining forever in do_page_fault()/hugetlb_fault()
and when interrupting that app, we get the following warning:
[162980.035629] WARNING: CPU: 0 PID: 2777 at arch/powerpc/mm/hugetlbpage.c:354
hugetlb_free_pgd_range+0xc8/0x1e4
[162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W 4.14.6 #85
[162980.035744] task: c67e2c00 task.stack: c668e000
[162980.035783] NIP: c000fe18 LR: c00e1eec CTR: c00f90c0
[162980.035830] REGS: c668fc20 TRAP: 0700 Tainted: G W(4.14.6)
[162980.035854] MSR: 00029032 CR: 24044224 XER: 2000
[162980.036003]
[162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 0010 c6869410 1008
77fb4000
[162980.036003] GPR08: 0001 0683c001 ff80 44028228 10018a34
4008 418004fc
[162980.036003] GPR16: c668e000 00040100 c668e000 c06c c668fe78 c668e000
c6835ba0 c668fd48
[162980.036003] GPR24: 73ff 7400 0001 77fb4000 100f
1010 1010
[162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4
[162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150
[162980.036861] Call Trace:
[162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214 (unreliable)
[162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150
[162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4
[162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8
[162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c
[162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc
[162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614
[162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244
[162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88
[162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4
[162980.037781] Instruction dump:
[162980.037821] 7fdff378 8137 54a3463a 80890020 7d24182e 7c841a14 712a0004
4082ff94
[162980.038014] 2f89 419e0010 712a0ff0 408200e0 <0fe0> 54a9000a
7f984840 419d0094
[162980.038216] ---[ end trace c0ceeca8e7a5800a ]---
[162980.038754] BUG: non-zero nr_ptes on freeing mm: 1
[162985.363322] BUG: non-zero nr_ptes on freeing mm: -1
In order to fix this, this patch uses the address space "slices"
implemented for BOOK3S/64 and enhanced to support PPC32 by the
preceding patch.
This patch modifies the context.id on the 8xx to be in the range
[1:16] instead of [0:15] in order to identify context.id == 0 as
not initialised contexts as done on BOOK3S
This patch activates CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE is
selected for the 8xx
Alltough we could in theory have as many slices as PMD entries, the
current slices implementation limits the number of low slices to 16.
This limitation is not preventing us to fix the initial issue allthough
it is suboptimal. It will be cured in a subsequent patch.
Fixes: 4b91428699477 ("powerpc/8xx: Implement support of hugepages")
Signed-off-by: Christophe Leroy
---
v2: First patch of v1 serie split in two parts
arch/powerpc/include/asm/mmu-8xx.h | 6 ++
arch/powerpc/kernel/setup-common.c | 2 ++
arch/powerpc/mm/8xx_mmu.c | 2 +-
arch/powerpc/mm/hugetlbpage.c | 2 ++
arch/powerpc/mm/mmu_context_nohash.c | 4 ++--
arch/powerpc/mm/slice.c| 2 ++
arch/powerpc/platforms/Kconfig.cputype | 1 +
7 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-8xx.h
b/arch/powerpc/include/asm/mmu-8xx.h
index 5bb3dbede41a..5f89b6010453 100644
--- a/arch/powerpc/include/asm/mmu-8xx.h
+++ b/arch/powerpc/include/asm/mmu-8xx.h
@@ -169,6 +169,12 @@ typedef struct {
unsigned int id;
unsigned int active;
unsigned long vdso_base;
+#ifdef CONFIG_PPC_MM_SLICES
+ u16 user_psize; /* page size index */
+ u64 low_slices_psize; /* page size encodings */
+ unsigned char high_slices_psize[0];
+ unsigned long slb_addr_limit;
+#endif
} mm_context_t;
#define PHYS_IMMR_BASE (mfspr(SPRN_IMMR) & 0xfff8)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 9d213542a48b..67075a1cff36 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -927,6 +927,8 @@ void __init setup_arch(char **cmdline_p)
#ifdef CONFIG_PPC64
if (!radix_enabled())
init_mm.context.slb_addr_limit = DEFAULT_MAP_WINDOW_USER64;
+#elif defined(CONF
[PATCH v2 4/5] powerpc/8xx: Increase the number of mm slices
On the 8xx, we can have as many slices as PMD entries.
This means we could have 1024 slices in 4k size pages mode
and 64 slices in 16k size pages.
However, due to a stack overflow in slice_get_unmapped_area(),
we limit to 512 slices.
Signed-off-by: Christophe Leroy
---
v2: no change
arch/powerpc/include/asm/mmu-8xx.h | 6 +-
arch/powerpc/include/asm/page_32.h | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-8xx.h
b/arch/powerpc/include/asm/mmu-8xx.h
index d669d0062da4..40aa7b0cd0dc 100644
--- a/arch/powerpc/include/asm/mmu-8xx.h
+++ b/arch/powerpc/include/asm/mmu-8xx.h
@@ -171,7 +171,11 @@ typedef struct {
unsigned long vdso_base;
#ifdef CONFIG_PPC_MM_SLICES
u16 user_psize; /* page size index */
- unsigned char low_slices_psize[8]; /* 16 slices */
+#if defined(CONFIG_PPC_16K_PAGES)
+ unsigned char low_slices_psize[32]; /* 64 slices */
+#else
+ unsigned char low_slices_psize[256]; /* 512 slices */
+#endif
unsigned char high_slices_psize[0];
unsigned long slb_addr_limit;
#endif
diff --git a/arch/powerpc/include/asm/page_32.h
b/arch/powerpc/include/asm/page_32.h
index f7d1bd1183c8..43695ce7ee07 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -62,7 +62,8 @@ extern void copy_page(void *to, void *from);
#ifdef CONFIG_PPC_MM_SLICES
-#define SLICE_LOW_SHIFT28
+/* SLICE_LOW_SHIFT >= 23 to avoid stack overflow in slice_get_unmapped_area()
*/
+#define SLICE_LOW_SHIFT(PMD_SHIFT > 23 ? PMD_SHIFT : 23)
#define SLICE_HIGH_SHIFT 0
#define SLICE_LOW_TOP (0xul)
--
2.13.3
[PATCH v2 3/5] powerpc/mm: Allow more than 16 low slices
While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices_psize
element in struct mm_context_t
On the 8xx, the minimum slice size is the size of the area
covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
16K pages mode. This means we could have resp. up to 1024 and 64
slices.
In order to override this limitation, this patch switches the
handling of low_slices to BITMAPs as done already for high_slices.
Signed-off-by: Christophe Leroy
---
v2: Usign slice_bitmap_xxx() macros instead of bitmap_xxx() functions.
arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
arch/powerpc/include/asm/mmu-8xx.h | 2 +-
arch/powerpc/include/asm/paca.h | 2 +-
arch/powerpc/kernel/paca.c | 3 +-
arch/powerpc/mm/hash_utils_64.c | 13 ++--
arch/powerpc/mm/slb_low.S| 8 ++-
arch/powerpc/mm/slice.c | 104 +--
7 files changed, 74 insertions(+), 60 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
b/arch/powerpc/include/asm/book3s/64/mmu.h
index c9448e19847a..27e7e9732ea1 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -91,7 +91,7 @@ typedef struct {
struct npu_context *npu_context;
#ifdef CONFIG_PPC_MM_SLICES
- u64 low_slices_psize; /* SLB page size encodings */
+ unsigned char low_slices_psize[8]; /* SLB page size encodings */
unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
unsigned long slb_addr_limit;
#else
diff --git a/arch/powerpc/include/asm/mmu-8xx.h
b/arch/powerpc/include/asm/mmu-8xx.h
index 5f89b6010453..d669d0062da4 100644
--- a/arch/powerpc/include/asm/mmu-8xx.h
+++ b/arch/powerpc/include/asm/mmu-8xx.h
@@ -171,7 +171,7 @@ typedef struct {
unsigned long vdso_base;
#ifdef CONFIG_PPC_MM_SLICES
u16 user_psize; /* page size index */
- u64 low_slices_psize; /* page size encodings */
+ unsigned char low_slices_psize[8]; /* 16 slices */
unsigned char high_slices_psize[0];
unsigned long slb_addr_limit;
#endif
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 23ac7fc0af23..0a6eea59a1c1 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -141,7 +141,7 @@ struct paca_struct {
#ifdef CONFIG_PPC_BOOK3S
mm_context_id_t mm_ctx_id;
#ifdef CONFIG_PPC_MM_SLICES
- u64 mm_ctx_low_slices_psize;
+ unsigned char mm_ctx_low_slices_psize[8];
unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
unsigned long mm_ctx_slb_addr_limit;
#else
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index d6597038931d..8e1566bf82b8 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -264,7 +264,8 @@ void copy_mm_to_paca(struct mm_struct *mm)
#ifdef CONFIG_PPC_MM_SLICES
VM_BUG_ON(!mm->context.slb_addr_limit);
get_paca()->mm_ctx_slb_addr_limit = mm->context.slb_addr_limit;
- get_paca()->mm_ctx_low_slices_psize = context->low_slices_psize;
+ memcpy(&get_paca()->mm_ctx_low_slices_psize,
+ &context->low_slices_psize, sizeof(context->low_slices_psize));
memcpy(&get_paca()->mm_ctx_high_slices_psize,
&context->high_slices_psize, TASK_SLICE_ARRAY_SZ(mm));
#else /* CONFIG_PPC_MM_SLICES */
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 3266b3326088..2f0c6b527a83 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1097,19 +1097,18 @@ unsigned int hash_page_do_lazy_icache(unsigned int pp,
pte_t pte, int trap)
#ifdef CONFIG_PPC_MM_SLICES
static unsigned int get_paca_psize(unsigned long addr)
{
- u64 lpsizes;
- unsigned char *hpsizes;
+ unsigned char *psizes;
unsigned long index, mask_index;
if (addr <= SLICE_LOW_TOP) {
- lpsizes = get_paca()->mm_ctx_low_slices_psize;
+ psizes = get_paca()->mm_ctx_low_slices_psize;
index = GET_LOW_SLICE_INDEX(addr);
- return (lpsizes >> (index * 4)) & 0xF;
+ } else {
+ psizes = get_paca()->mm_ctx_high_slices_psize;
+ index = GET_HIGH_SLICE_INDEX(addr);
}
- hpsizes = get_paca()->mm_ctx_high_slices_psize;
- index = GET_HIGH_SLICE_INDEX(addr);
mask_index = index & 0x1;
- return (hpsizes[index >> 1] >> (mask_index * 4)) & 0xF;
+ return (psizes[index >> 1] >> (mask_index * 4)) & 0xF;
}
#else
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index 2cf5ef3fc50d..2c7c717fd2ea 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -200,10 +200,12 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
5:
/*
* Handle lpsize
Re: [BUG 4.15-rc7] IRQ matrix management errors
On Wed, 17 Jan 2018, Keith Busch wrote: > On Wed, Jan 17, 2018 at 08:34:22AM +0100, Thomas Gleixner wrote: > > Can you trace the matrix allocations from the very beginning or tell me how > > to reproduce. I'd like to figure out why this is happening. > > Sure, I'll get the irq_matrix events. > > I reproduce this on a machine with 112 CPUs and 3 NVMe controllers. The > first two NVMe want 112 MSI-x vectors, and the last only 31 vectors. The > test runs 'modprobe nvme' and 'modprobe -r nvme' in a loop with 10 > second delay between each step. Repro occurs within a few iterations, > sometimes already broken after the initial boot. That doesn't sound right. The vectors should be spread evenly accross the CPUs. So ENOSPC should never happen. Can you please take snapshots of /sys/kernel/debug/irq/ between the modprobe and modprobe -r steps? Thanks, tglx
Re: ipv6 redefinition build issue with 4.15-rc8
On 01/17/2018 08:59 AM, Daniel Wagner wrote: Hi Neil, On 01/16/2018 07:51 PM, Neil MacLeod wrote: Since this commit in 4.15-rc8: https://github.com/torvalds/linux/commit/6926e041a8920c8ec27e4e155efa760aa01551fd building connman 1.35 with glibc 2.26 now fails as follows: http://ix.io/EbP I'm not sure if this is a kernel issue, a glibc issue, or a connman issue. Reverting the kernel commit resolves the issue, but isn't ideal (unless it's the correct solution, of course). Does anyone have any better ideas? Try switching the order of these headers around (src/tethering.c)... netinet/in.h seems to depend on linux/in.h being included _first_ and it's presumably being pulled in via linux/if_bridge.h now as a result of the kernel patch (couldn't immediately see why, though... I suspect the inclusion of libc-compat.h is the culprit.) #include #include Yes, this is a hack and only masks the issue... nonetheless. /Jonas Since ConnMan does not redefine 'struct in6_addr' and friends I would say it is kernel/glibc header include problem. But I might be wrong here. @Hauke: Do you happen to know what is going on? Thanks, Daniel ___ connman mailing list conn...@lists.01.org https://lists.01.org/mailman/listinfo/connman
Re: [PATCH 03/16] x86/entry/32: Leave the kernel via the trampoline stack
On Tue, Jan 16, 2018 at 02:48:43PM -0800, Andy Lutomirski wrote: > On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote: > > + /* Restore user %edi and user %fs */ > > + movl (%edi), %edi > > + popl %fs > > Yikes! We're not *supposed* to be able to observe an asynchronous > descriptor table change, but if the LDT changes out from under you, > this is going to blow up badly. It would be really nice if you could > pull this off without percpu access or without needing to do this > dance where you load user FS, then kernel FS, then user FS. If that's > not doable, then you should at least add exception handling -- look at > the other 'pop %fs' instructions in entry_32.S. You are right! This also means I need to do the 'popl %fs' before the cr3-switch. I'll fix it in the next version. I have no real idea on how to switch back to the entry stack without access to per_cpu variables. I also can't access the cpu_entry_area for the cpu yet, because for that we need to be on the entry stack already. Joerg
Re: [PATCH V4 1/2] nvme: add NVME_CTRL_RESET_PREPARE state
Hi max
On 01/17/2018 05:19 PM, jianchao.wang wrote:
> Hi Max
>
> Thanks for your kindly response.
>
> I have merged the response to you together below.
> On 01/17/2018 05:06 PM, Max Gurtovoy wrote:
>>> case NVME_CTRL_RECONNECTING:
>>> switch (old_state) {
>>> case NVME_CTRL_LIVE:
>>> - case NVME_CTRL_RESETTING:
>>> + case NVME_CTRL_RESET_PREPARE:
>>
>> As I suggested in V3, please don't allow this transition.
>> We'll move to NVME_CTRL_RECONNECTING from NVME_CTRL_RESETTING.
>>
>> I look on it like that:
>>
>> NVME_CTRL_RESET_PREPARE - "suspend" state
>> NVME_CTRL_RESETTING - "resume" state
>>
>> you don't reconnect from "suspend" state, you must "resume" before you
>> reconnect.
>
>>> index d49b1e7..6b5f2f4 100644
>>> --- a/drivers/nvme/host/rdma.c
>>> +++ b/drivers/nvme/host/rdma.c
>>> @@ -985,7 +985,7 @@ static void nvme_rdma_error_recovery_work(struct
>>> work_struct *work)
>>> static void nvme_rdma_error_recovery(struct nvme_rdma_ctrl *ctrl)
>>> {
>>> - if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESETTING))
>>> + if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESET_PREPARE))
>>> return;
>>
>> We can add a NVME_CTRL_RESET_PREPARE --> NVME_CTRL_RESETTING transition and
>> then move to NVME_CTRL_RECONNECTING (in nvme_rdma_reset_ctrl_work and
>> nvme_rdma_error_recovery_work).
>> I want to add an ability to recover from device removal (actually wanted to
>> send it today but I'm waiting to see what will happen with this patchset)
>> for RDMA and your approach (enable transition to from both "suspend" and
>> "resume" to "reconnect") might be problematic.
>>
>> Sagi/Christoph ?
>
> I used to respond you in the V3 and wait for your feedback.
> Please refer to:
> After Sagi's nvme-rdma: fix concurrent reset and reconnect, the rdma ctrl
> state is changed to RECONNECTING state
> after some clearing and shutdown work, then some initializing procedure, no
> matter reset work path or error recovery path.
> The fc reset work also does the same thing.
> So if we define the range that RESET_PREPARE includes scheduling gap and
> disable and clear work, RESETTING includes initializing
> procedure, RECONNECTING is very similar with RESETTING.
>
> Maybe we could do like this;
> In nvme fc/rdma
> - set state to RESET_PREPARE, queue reset_work/err_work
> - clear/shutdown works, set state to RECONNECTING
> - initialization, set state to LIVE
>
> In nvme pci
> - set state to RESET_PREPARE, queue reset_work
> - clear/shutdown works, set state to RESETTING
> - initialization, set state to LIVE
>
> Currently, RECONNECTING has overlapped with RESETTING.
> So I suggest to use RESET_PREPARE to mark the "suspend" part as you said.
> And use RECONNECTING to mark the "resume" part in nvme-rdma/fc
> use RESETTING part to mark the "resume" part in nvme-pci, nvmt-loop.
I have added a comment above the definition of nvme_ctrl_state as below:
+/*
+ * RESET_PREPARE - mark the state of scheduling gap and disable procedure
+ * RESETTING - nvme-pci, nvmet loop use it to mark the state of setup
+ * procedure
+ * RECONNECTING - nvme-fc, nvme-rdma use it to mark the state of setup
+ * and reconnect procedure
+ */
Consequently, nvme-fc/rdma don't use RESETTING state any more, but only
RESET_PREPARE.
Thanks
Jianchao
>
> I want to confirm with all of you, but no none had feedback, so I sent out
> the patch directly.
> Please forgive my abrupt actions.
>
> Thanks
> Jianchao
>
> ___
> Linux-nvme mailing list
> linux-n...@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwIGAA&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=7WdAxUBeiTUTCy8v-7zXyr4qk7sx26ATvfo6QSTvZyQ&m=lUkrKY6u8mGr5k1ajcQSKfsk1N2wKpmD60MJfojz4iY&s=AtvJd5ElCQ_WoO2Q5-LBTEdlZeTmWOHEGO-baUZyl-o&e=
>
Re: [PATCH] irqdomain: provide useful debugging information for irq domain
On 17/01/18 09:18, Thomas Gleixner wrote: > On Wed, 17 Jan 2018, Marc Zyngier wrote: >> In all honesty, I'd be more inclined to remove this debug feature >> altogether, as CONFIG_GENERIC_IRQ_DEBUGFS is more complete and more >> useful. Is there any feature missing from that infrastructure that >> prevents you from using it instead? >> >> If the answer is "none", then I'll post a patch removing it. > > Wanted to do that quite some time ago and never came around to it. Same here, but got slightly sidetracked lately. I'll post something later today. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH] irqdomain: provide useful debugging information for irq domain
Hi, Marc and Thomas, Thanks for your feedback. On Wed, 2018-01-17 at 10:18 +0100, Thomas Gleixner wrote: > On Wed, 17 Jan 2018, Marc Zyngier wrote: > > > > In all honesty, I'd be more inclined to remove this debug feature > > altogether, as CONFIG_GENERIC_IRQ_DEBUGFS is more complete and more > > useful. Is there any feature missing from that infrastructure that > > prevents you from using it instead? > > > > If the answer is "none", then I'll post a patch removing it. > Wanted to do that quite some time ago and never came around to it. I think they have different purpose. irq_domain_mapping is an overiew of the mapping of each virq to hwirq and the domain it belongs. It likes a map or index of each IRQs. I tend to suggest to keep it. The nodes under debugfs irq/domains describes the hierarchy of each irq domain. The nodes under debugfs irq/irqs describes information of every single irq. Thanks Shunyong
Re: [PATCH 04/16] x86/pti: Define X86_CR3_PTI_PCID_USER_BIT on x86_32
On Tue, Jan 16, 2018 at 02:46:16PM -0800, Andy Lutomirski wrote: > On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote: > > From: Joerg Roedel > > > > Move it out of the X86_64 specific processor defines so > > that its visible for 32bit too. > > Hmm. This is okay, I guess, but any code that actually uses this > definition is inherently wrong, since 32-bit implies !PCID. Yes, I tried another approach first which just #ifdef'ed out the relevant parts in tlbflush.h which use this bit. But that seemed to be the wrong path, as there is more PCID code that is compiled in for 32 bit. So defining the bit for 32 bit seemed to be the cleaner solution for now. Joerg
Re: [RESEND PATCH 1/3] x86/apic: Set up through LAPIC on boot CPU's LINT0 if ioapic is disabled
CC Eric
On 01/05/18 at 12:37pm, Baoquan He wrote:
> Kdump kernel will become very slow if 'noapic' is specified in kernel
> command line. Normal kernel doesn't have this issue.
>
> This is because the legacy irq mode is disabled in crashed kernel before
> jump jump to kdump kernel since commit 522e664644 ("x86/apic: Disable I/O
> APIC before shutdown of the local APIC") is merged. While in normal kernel,
> the legacy irq mode has been set in BIOS.
>
> So we need set the delivery mode AS ExtINT for LVT0 of boot CPU's LAPIC
> explicitly if IO-APIC is disabled, to set up through-local-APIC.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/kernel/apic/apic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 880441f24146..7e613fb90630 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1521,7 +1521,7 @@ void setup_local_APIC(void)
>* TODO: set up through-local-APIC from through-I/O-APIC? --macro
>*/
> value = apic_read(APIC_LVT0) & APIC_LVT_MASKED;
> - if (!cpu && (pic_mode || !value)) {
> + if (!cpu && (pic_mode || !value || skip_ioapic_setup)) {
> value = APIC_DM_EXTINT;
> apic_printk(APIC_VERBOSE, "enabled ExtINT on CPU#%d\n", cpu);
> } else {
> --
> 2.5.5
>
Re: [Nouveau] [PATCH] drm/nouveau/bar/gk20a: Avoid bar teardown during init
On 10/01/18 12:20, Thierry Reding wrote:
On Thu, Jan 04, 2018 at 11:29:09AM +, Jon Hunter wrote:
Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
introduced add a teardown helper function for BAR1. During
initialisation of the Nouveau, initially all the teardown helpers are
called once, before calling their init counterparts. For gk20a, after
the BAR1 teardown function is called, the device is hanging during the
initialisation of the FB sub-device. At this point it is unclear why
this is happening and this is still under investigation. However, this
change is preventing Tegra124 devices from booting when Nouveau is
enabled. To allow Tegra124 to boot, remove the teardown helper for
gk20a.
This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.
Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: Guillaume Tucker
Signed-off-by: Jon Hunter
---
I am not happy that we do not yet fully understand the cause of
the hang, but I am talking with a few people at NVIDIA about this
and have a few things to look into. However, given that we are
close to v4.15 being released and I am not sure we will have a
proper fix in place before, I think it is best to workaround
this for now.
drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c | 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Thierry Reding
Tested-by: Guillaume Tucker
https://lava.collabora.co.uk/scheduler/job/1047172
Thanks for this workaround. Looking forward to having this
platform back on track in mainline. I'm happy to run this boot
test again with a proper fix in future patches, let me know if I
can be of any help.
Guillaume
Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
> On 01/17/2018 04:21 PM, Pankaj Gupta wrote:
> >> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
> >> support of reporting hints of guest free pages to host via virtio-balloon.
> >>
> >> Host requests the guest to report free pages by sending a new cmd
> >> id to the guest via the free_page_report_cmd_id configuration register.
> >>
> >> When the guest starts to report, the first element added to the free page
> >> vq is the cmd id given by host. When the guest finishes the reporting
> >> of all the free pages, VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID is added
> >> to the vq to tell host that the reporting is done. Host may also requests
> >> the guest to stop the reporting in advance by sending the stop cmd id to
> >> the guest via the configuration register.
> >>
> >> Signed-off-by: Wei Wang
> >> Signed-off-by: Liang Li
> >> Cc: Michael S. Tsirkin
> >> Cc: Michal Hocko
> >> ---
> >> drivers/virtio/virtio_balloon.c | 242
> >> +++-
> >> include/uapi/linux/virtio_balloon.h | 4 +
> >> 2 files changed, 214 insertions(+), 32 deletions(-)
> >>
> >> diff --git a/drivers/virtio/virtio_balloon.c
> >> b/drivers/virtio/virtio_balloon.c
> >> index a1fb52c..b9561a5 100644
> >> --- a/drivers/virtio/virtio_balloon.c
> >> +++ b/drivers/virtio/virtio_balloon.c
> >> @@ -53,7 +53,12 @@ static struct vfsmount *balloon_mnt;
> >>
> >> struct virtio_balloon {
> >> struct virtio_device *vdev;
> >> -struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> >> +struct virtqueue *inflate_vq, *deflate_vq, *stats_vq,
> >> *free_page_vq;
> >> +
> >> +/* Balloon's own wq for cpu-intensive work items */
> >> +struct workqueue_struct *balloon_wq;
> >> +/* The free page reporting work item submitted to the balloon wq
> >> */
> >> +struct work_struct report_free_page_work;
> >>
> >> /* The balloon servicing is delegated to a freezable workqueue.
> >> */
> >> struct work_struct update_balloon_stats_work;
> >> @@ -63,6 +68,13 @@ struct virtio_balloon {
> >> spinlock_t stop_update_lock;
> >> bool stop_update;
> >>
> >> +/* Start to report free pages */
> >> +bool report_free_page;
> >> +/* Stores the cmd id given by host to start the free page
> >> reporting */
> >> +uint32_t start_cmd_id;
> >> +/* Stores STOP_ID as a sign to tell host that the reporting is
> >> done */
> >> +uint32_t stop_cmd_id;
> >> +
> >> /* Waiting for host to ack the pages we released. */
> >> wait_queue_head_t acked;
> >>
> >> @@ -281,6 +293,71 @@ static unsigned int update_balloon_stats(struct
> >> virtio_balloon *vb)
> >> return idx;
> >> }
> >>
> >> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t
> >> len)
> >> +{
> >> +struct scatterlist sg;
> >> +unsigned int unused;
> >> +int err;
> >> +
> >> +sg_init_table(&sg, 1);
> >> +sg_set_page(&sg, pfn_to_page(pfn), len, 0);
> >> +
> >> +/* Detach all the used buffers from the vq */
> >> +while (virtqueue_get_buf(vq, &unused))
> >> +;
> >> +
> >> +/*
> >> + * Since this is an optimization feature, losing a couple of free
> >> + * pages to report isn't important. We simply resturn without
> >> adding
> >> + * the page if the vq is full. We are adding one entry each time,
> >> + * which essentially results in no memory allocation, so the
> >> + * GFP_KERNEL flag below can be ignored.
> >> + */
> >> +if (vq->num_free) {
> >> +err = virtqueue_add_inbuf(vq, &sg, 1, vq, GFP_KERNEL);
> >> +/*
> >> + * This is expected to never fail, because there is
> >> always an
> >> + * entry available on the vq.
> >> + */
> >> +BUG_ON(err);
> >> +}
> >> +}
> >> +
> >> +static void batch_free_page_sg(struct virtqueue *vq,
> >> + unsigned long pfn,
> >> + uint32_t len)
> >> +{
> >> +add_one_sg(vq, pfn, len);
> >> +
> >> +/* Batch till the vq is full */
> >> +if (!vq->num_free)
> >> +virtqueue_kick(vq);
> >> +}
> >> +
> >> +static void send_cmd_id(struct virtqueue *vq, void *addr)
> >> +{
> >> +struct scatterlist sg;
> >> +unsigned int unused;
> >> +int err;
> >> +
> >> +sg_init_one(&sg, addr, sizeof(uint32_t));
> >> +
> >> +/*
> >> + * This handles the cornercase that the vq happens to be full when
> >> + * adding a cmd id. Rarely happen in practice.
> >> + */
> >> +while (!vq->num_free)
> >> +virtqueue_get_buf(vq, &unused);
> >> +
> >> +err = virtqueue_add_outbuf(vq, &sg, 1, vq, GFP_KERNEL);
> >> +/*
> >> +
Re: [REGRESSION] linux-next panics when trying to mount root
On 2018-01-17 09:27, Rafał Miłecki wrote: > On 2018-01-16 14:28, Peter Rosin wrote: >> When trying next-20180116 I get the following panic during boot: >> >> Linux version 4.15.0-rc8-next-20180116 (peda@orc) (gcc version 4.9.2 >> 20140811 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.08 - Linaro >> GCC 4.9-2014.08)) #208 Tue Jan 16 14:23:44 CET 2018 >> CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d >> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction >> cache >> OF: fdt: Machine model: Axentia Linea-Nattis v2 Natte v2 >> Memory policy: Data cache writeback >> CPU: All CPU(s) started in SVC mode. >> random: fast init done >> Built 1 zonelists, mobility grouping on. Total pages: 16256 >> Kernel command line: console=ttyS0,115200 rw consoleblank=0 ip=none >> root=ubi0:rootfs ubi.mtd=6 rootfstype=ubifs noinitrd >> mtdparts=atmel_nand:256k(at91bootstrap),384k(barebox)ro,256k@768k(bareboxenv),256k(bareboxenv2),128k@1536k(oftree),5M@2M(kernel),-@8M(rootfs) >> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) >> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) >> Memory: 56244K/65536K available (5120K kernel code, 183K rwdata, 1064K >> rodata, 1024K init, 108K bss, 9292K reserved, 0K cma-reserved) >> Virtual kernel memory layout: >> vector : 0x - 0x1000 ( 4 kB) >> fixmap : 0xffc0 - 0xfff0 (3072 kB) >> vmalloc : 0xc480 - 0xff80 ( 944 MB) >> lowmem : 0xc000 - 0xc400 ( 64 MB) >> .text : 0x(ptrval) - 0x(ptrval) (6112 kB) >> .init : 0x(ptrval) - 0x(ptrval) (1024 kB) >> .data : 0x(ptrval) - 0x(ptrval) ( 184 kB) >>.bss : 0x(ptrval) - 0x(ptrval) ( 109 kB) >> NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 >> clocksource: pit: mask: 0xfff max_cycles: 0xfff, max_idle_ns: >> 14479245754 ns >> sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every >> 2147483647500ns >> Console: colour dummy device 80x30 >> Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184) >> pid_max: default: 32768 minimum: 301 >> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) >> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) >> CPU: Testing write buffer coherency: ok >> Setting up static identity map for 0x2010 - 0x20100060 >> devtmpfs: initialized >> VFP support v0.3: implementor 41 architecture 2 part 30 variant 5 rev 1 >> clocksource: jiffies: mask: 0x max_cycles: 0x, >> max_idle_ns: 1911260446275 ns >> futex hash table entries: 256 (order: -1, 3072 bytes) >> pinctrl core: initialized pinctrl subsystem >> NET: Registered protocol family 16 >> DMA: preallocated 256 KiB pool for atomic coherent allocations >> AT91: PM: standby: standby, suspend: ulp0 >> No ATAGs? >> gpio-at91 f200.gpio: at address 45a5b6d3 >> gpio-at91 f400.gpio: at address d0c9dba6 >> gpio-at91 f600.gpio: at address fb737fc9 >> gpio-at91 f800.gpio: at address c5aa2ee6 >> gpio-at91 fa00.gpio: at address 4663f5ca >> pinctrl-at91 ahb:apb:pinctrl@f200: initialized AT91 pinctrl driver >> clocksource: tcb_clksrc: mask: 0x max_cycles: 0x, >> max_idle_ns: 115833966437 ns >> at_hdmac e600.dma-controller: Atmel AHB DMA Controller ( cpy set >> slave ), 8 channels >> at_hdmac e800.dma-controller: Atmel AHB DMA Controller ( cpy set >> slave ), 8 channels >> AT91: Detected SoC family: sama5d3 >> AT91: Detected SoC: sama5d31, revision 2 >> usbcore: registered new interface driver usbfs >> usbcore: registered new interface driver hub >> usbcore: registered new device driver usb >> at91_i2c f0014000.i2c: using dma0chan0 (tx) and dma0chan1 (rx) for DMA >> transfers >> at91_i2c f0014000.i2c: AT91 i2c bus driver (hw version: 0x402). >> clocksource: Switched to clocksource tcb_clksrc >> NET: Registered protocol family 2 >> tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes) >> TCP established hash table entries: 1024 (order: 0, 4096 bytes) >> TCP bind hash table entries: 1024 (order: 0, 4096 bytes) >> TCP: Hash tables configured (established 1024 bind 1024) >> UDP hash table entries: 256 (order: 0, 4096 bytes) >> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) >> NET: Registered protocol family 1 >> Initialise system trusted keyrings >> workingset: timestamp_bits=30 max_order=14 bucket_order=0 >> Key type asymmetric registered >> Asymmetric key parser 'x509' registered >> io scheduler noop registered (default) >> io scheduler mq-deadline registered >> io scheduler kyber registered >> f001c000.serial: ttyS1 at MMIO 0xf001c000 (irq = 22, base_baud = >> 4125000) is a ATMEL_SERIAL >> ee00.serial: ttyS0 at MMIO 0xee00 (irq = 30, base_baud = >> 825) is a ATMEL_SERIAL >> console [ttyS0] enabled >> loop: module loaded >> ssc f0008000.ssc: Atmel SSC device at 0x6a12493c (irq 19) >> ssc f0008000.ssc: failed to auto-setup ssc for audio >> at24 0-0051: 8192 byte 24c64 EEPROM, writable, 32 b
Re: [PATCH 06/19] drm/blend: Add a generic alpha property
On Wed, Jan 17, 2018 at 10:20:24AM +0100, Maxime Ripard wrote: > On Thu, Jan 11, 2018 at 08:34:58PM +0200, Laurent Pinchart wrote: > > Hi Daniel, > > > > On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote: > > > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > > > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > > > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > > > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > > > > Some drivers duplicate the logic to create a property to store a > > > > per-plane alpha. > > > > > > > > Let's create a helper in order to move that to the core. > > > > > > > > Cc: Boris Brezillon > > > > Cc: Laurent Pinchart > > > > Signed-off-by: Maxime Ripard > > > > > > Do we have userspace for this? > > > >>> > > > >>> Wayland seems to be on its way to implement this, with ChromeOS using > > > >>> it: > > > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741 > > > >>> .html > > > >>> > > > >>> and more specifically: > > > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way > > > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1 > > > >>> .xml#118 > > > >> > > > >> Yay, would be good to include these links in the patch description. > > > >> Really happy we're having a real standard now used by multiple people. > > > > > > > > I will. > > > > > > > >> > > Is encoding a fixed 0-255 range really the best idea? > > > >> > > > > >> > I don't really know, is there hardware or formats where there is more > > > >> > than 255? Or did you mean less than that? > > > >> > > > >> 30bit I'd assume wants more alpha. In the past we've done some > > > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using > > > >> that for the blend equation docs is also what I recommend (and that we > > > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of > > > >> that > > > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's > > > >> what we're doing for gamma tables already, and that way drivers can > > > >> simply throw away the lower bits. > > > > > > > > But that would also break the two users of that property that won't be > > > > able to move to the generic property (with the same name) without > > > > breaking userspace. The point of that patch was to allow some code > > > > consolidation, and that would mean failing to do so here :/ > > > > > > Let me try to clarify: > > > - We'll keep the exact existing property semantics with the 0-255 > > > range for the userspace visible property. > > > > > > - But internally, in the decode value that we store into > > > drm_plane_state, we'll do the slightly more future proof thing with a > > > few more bits. > > > > > > That gives us the option of exposing those bits in the future without > > > having to change all the drivers again (which we have to do for this > > > series here already anyway, since the decoded value moves into > > > drm_plane_state from driver subclasses). > > > > > > Definitely not asking to break userspace here :-) > > > > As the property range is available to userspace, we could allow drivers to > > expose a driver-dependent number of bits for the alpha value without > > breaking > > anything. We can even require new drivers to expose 16 bits regardless of > > the > > number of bits that the hardware can handle, or we could keep that driver- > > specific. > > > > Please note, however, that U0.16 can only represent [0.0, 0.84741...] > > while we need [0.0, 1.0]. As all the hardware I know map the full range of > > values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend > > that > > the 16-bit value exposed to userspace is U0.16. > > So this would involve not changing too much the current patch, but > instead extending the type from an u8 to an u16. Would that work for > you Daniel? Yeah, Laurent's clarification is what I've meant ... And hopefully it's enough future-proofing that we don't need to redo this all again. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RESEND PATCH 2/3] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel
CC Eric
On 01/05/18 at 12:38pm, Baoquan He wrote:
> In commit
>
> commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local
> APIC").
>
> lapic_shutdown() invocation is moved after disable_IO_APIC(). In fact
> in disable_IO_APIC(), it not only calls clear_IO_APIC() to disable
> IO-APIC, also sets sets LAPIC and IO-APIC to make system be PIC or
> Virtual wire mode. While the above commit putting disable_IO_APIC earlier
> causes local APIC is completely disabled. So the legacy irq mode is
> disabled too before jump to kexec/kdump kernel.
>
> In normal kernel it defaults to be PIC mode or Virtual Wire mode during
> system initialization before APIC mode is enabled and this is done by
> BIOS initialization. But kexec/kdump kernel won't go through BIOS, so
> we should set system as PIC or Virtual Wire mode before jump to kdump
> kernel code directly.
>
> So let's take clear_IO_APIC out from disable_IO_APIC and rename
> disable_IO_APIC as switch_to_legacy_irq_mode. Then only call clear_IO_APIC
> when IO-APIC need be disabled. And call switch_to_legacy_irq_mode before
> kexec/kdump jumping.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/include/asm/io_apic.h | 3 ++-
> arch/x86/kernel/apic/io_apic.c | 12
> arch/x86/kernel/crash.c| 2 +-
> arch/x86/kernel/machine_kexec_32.c | 15 +--
> arch/x86/kernel/machine_kexec_64.c | 15 +--
> arch/x86/kernel/reboot.c | 2 +-
> 6 files changed, 18 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> index a8834dd546cd..e38ad3863a2c 100644
> --- a/arch/x86/include/asm/io_apic.h
> +++ b/arch/x86/include/asm/io_apic.h
> @@ -192,7 +192,8 @@ static inline unsigned int io_apic_read(unsigned int
> apic, unsigned int reg)
>
> extern void setup_IO_APIC(void);
> extern void enable_IO_APIC(void);
> -extern void disable_IO_APIC(void);
> +extern void clear_IO_APIC (void);
> +extern void switch_to_legacy_irq_mode(void);
> extern int IO_APIC_get_PCI_irq_vector(int bus, int devfn, int pin);
> extern void print_IO_APICs(void);
> #else /* !CONFIG_X86_IO_APIC */
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 8a7963421460..a47aa915d18c 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -587,7 +587,7 @@ static void clear_IO_APIC_pin(unsigned int apic, unsigned
> int pin)
> mpc_ioapic_id(apic), pin);
> }
>
> -static void clear_IO_APIC (void)
> +void clear_IO_APIC (void)
> {
> int apic, pin;
>
> @@ -1439,15 +1439,11 @@ void native_disable_io_apic(void)
> }
>
> /*
> - * Not an __init, needed by the reboot code
> + * Not an __init, needed by kexec/kdump code.
> + * For safety IO-APIC and Local APIC need be cleared before this.
> */
> -void disable_IO_APIC(void)
> +void switch_to_legacy_irq_mode(void)
> {
> - /*
> - * Clear the IO-APIC before rebooting:
> - */
> - clear_IO_APIC();
> -
> if (!nr_legacy_irqs())
> return;
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 10e74d4778a1..318ffeaaf55a 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -199,7 +199,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> #ifdef CONFIG_X86_IO_APIC
> /* Prevent crash_kexec() from deadlocking on ioapic_lock. */
> ioapic_zap_locks();
> - disable_IO_APIC();
> + clear_IO_APIC();
> #endif
> lapic_shutdown();
> #ifdef CONFIG_HPET_TIMER
> diff --git a/arch/x86/kernel/machine_kexec_32.c
> b/arch/x86/kernel/machine_kexec_32.c
> index edfede768688..7ab10d930cc6 100644
> --- a/arch/x86/kernel/machine_kexec_32.c
> +++ b/arch/x86/kernel/machine_kexec_32.c
> @@ -190,18 +190,13 @@ void machine_kexec(struct kimage *image)
> local_irq_disable();
> hw_breakpoint_disable();
>
> - if (image->preserve_context) {
> #ifdef CONFIG_X86_IO_APIC
> - /*
> - * We need to put APICs in legacy mode so that we can
> - * get timer interrupts in second kernel. kexec/kdump
> - * paths already have calls to disable_IO_APIC() in
> - * one form or other. kexec jump path also need
> - * one.
> - */
> - disable_IO_APIC();
> + /*
> + * We need to put APICs in legacy mode so that we can
> + * get timer interrupts in second kernel.
> + */
> + switch_to_legacy_irq_mode();
> #endif
> - }
>
> control_page = page_address(image->control_code_page);
> memcpy(control_page, relocate_kernel, KEXEC_CONTROL_CODE_MAX_SIZE);
> diff --git a/arch/x86/kernel/machine_kexec_64.c
> b/arch/x86/kernel/machine_kexec_64.c
> index 1f790cf9d38f..b5c0cbed6791 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -288,18 +288,13 @@ void machine_kexec(struct kimage *im
Re: [RESEND PATCH 3/3] x86/apic: Clean up the names of legacy irq mode setting related functions
CC Eric
On 01/05/18 at 12:39pm, Baoquan He wrote:
> X86 MP spec defines 3 different interrupt modes:
> 1) PIC Mode—bypasses all APIC components and forces the system to
> operate in single-processor mode.
> 2) Virtual Wire Mode—uses an APIC as a virtual wire, but otherwise
> operates the same as PIC Mode.
> 3) Symmetric I/O Mode—enables the system to operate with more than
> one processor.
>
> The current disconnect_bsp_APIC includes two parts: one is to set system
> as PIC mode if it's available, the other is to change system back to
> Virtual Wire mode. Only PIC mode will detach the APIC from the interrupt
> system, Virtual Wire mode doesn't.
>
> Besides Virutal Wire mode has two kinds: one is only setting Local APIC
> as Virtual Wire mode and interrupts are delivered from the PIC to the
> CPU which Local APIC connected to, the other is both Loca APIC and IO-APIC
> need be set as Virtual Wire mode.
>
> So based on above knowledge, take IO-APIC Virtual Wire mode setting code
> out and wrap it inot a new function ioapic_set_virtual_wire_mode. Meanwhile
> change the name of disconnect_bsp_APIC as lapic_set_legacy_irq_mode. These
> makes the legacy irq mode setting more understandable.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/include/asm/apic.h| 2 +-
> arch/x86/include/asm/io_apic.h | 5 ++---
> arch/x86/kernel/apic/apic.c| 11 ++-
> arch/x86/kernel/apic/io_apic.c | 17 ++---
> arch/x86/kernel/x86_init.c | 2 +-
> drivers/iommu/irq_remapping.c | 2 +-
> 6 files changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
> index a9e57f08bfa6..004c48bc8bc8 100644
> --- a/arch/x86/include/asm/apic.h
> +++ b/arch/x86/include/asm/apic.h
> @@ -132,7 +132,7 @@ extern int get_physical_broadcast(void);
>
> extern int lapic_get_maxlvt(void);
> extern void clear_local_APIC(void);
> -extern void disconnect_bsp_APIC(int virt_wire_setup);
> +extern void lapic_set_legacy_irq_mode(int virt_wire_setup);
> extern void disable_local_APIC(void);
> extern void lapic_shutdown(void);
> extern void sync_Arb_IDs(void);
> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> index e38ad3863a2c..6800dcea1d21 100644
> --- a/arch/x86/include/asm/io_apic.h
> +++ b/arch/x86/include/asm/io_apic.h
> @@ -183,7 +183,7 @@ extern void disable_ioapic_support(void);
>
> extern void __init io_apic_init_mappings(void);
> extern unsigned int native_io_apic_read(unsigned int apic, unsigned int reg);
> -extern void native_disable_io_apic(void);
> +extern void switch_to_legacy_irq_mode(void);
>
> static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
> {
> @@ -193,7 +193,6 @@ static inline unsigned int io_apic_read(unsigned int
> apic, unsigned int reg)
> extern void setup_IO_APIC(void);
> extern void enable_IO_APIC(void);
> extern void clear_IO_APIC (void);
> -extern void switch_to_legacy_irq_mode(void);
> extern int IO_APIC_get_PCI_irq_vector(int bus, int devfn, int pin);
> extern void print_IO_APICs(void);
> #else /* !CONFIG_X86_IO_APIC */
> @@ -229,7 +228,7 @@ static inline void mp_save_irq(struct mpc_intsrc *m) { }
> static inline void disable_ioapic_support(void) { }
> static inline void io_apic_init_mappings(void) { }
> #define native_io_apic_read NULL
> -#define native_disable_io_apic NULL
> +#define switch_to_legacy_irq_modeNULL
>
> static inline void setup_IO_APIC(void) { }
> static inline void enable_IO_APIC(void) { }
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 7e613fb90630..301d90d4a0c3 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2050,13 +2050,14 @@ static void __init connect_bsp_APIC(void)
> }
>
> /**
> - * disconnect_bsp_APIC - detach the APIC from the interrupt system
> - * @virt_wire_setup: indicates, whether virtual wire mode is selected
> + * lapic_set_legacy_irq_mode - switch Local APIC back to be legacy irq mode.
> + * @virt_wire_setup: indicates, whether virtual wire mode is selected
> *
> - * Virtual wire mode is necessary to deliver legacy interrupts even when the
> - * APIC is disabled.
> + * If PIC mode is available, LAPIC need be disconnected with CPU. Otherwise
> + * enable LAPIC and set it to be virtual wire mode. However if IO-APIC has
> + * been virtual wire mode, LVT0 of LAPIC need be masked.
> */
> -void disconnect_bsp_APIC(int virt_wire_setup)
> +void lapic_set_legacy_irq_mode(int virt_wire_setup)
> {
> unsigned int value;
>
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index a47aa915d18c..b7fd4236b0e5 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -1410,7 +1410,7 @@ void __init enable_IO_APIC(void)
> clear_IO_APIC();
> }
>
> -void native_disable_io_apic(void)
> +static void ioapic_set_virtual_wire_mode(void)
Re: [BUG 4.15-rc7] IRQ matrix management errors
On Wed, 17 Jan 2018, Thomas Gleixner wrote: > On Wed, 17 Jan 2018, Keith Busch wrote: > > On Wed, Jan 17, 2018 at 08:34:22AM +0100, Thomas Gleixner wrote: > > > Can you trace the matrix allocations from the very beginning or tell me > > > how > > > to reproduce. I'd like to figure out why this is happening. > > > > Sure, I'll get the irq_matrix events. > > > > I reproduce this on a machine with 112 CPUs and 3 NVMe controllers. The > > first two NVMe want 112 MSI-x vectors, and the last only 31 vectors. The > > test runs 'modprobe nvme' and 'modprobe -r nvme' in a loop with 10 > > second delay between each step. Repro occurs within a few iterations, > > sometimes already broken after the initial boot. > > That doesn't sound right. The vectors should be spread evenly accross the > CPUs. So ENOSPC should never happen. > > Can you please take snapshots of /sys/kernel/debug/irq/ between the > modprobe and modprobe -r steps? The allocation fails because CPU1 has exhausted it's vector space here: [002] d... 333.028216: irq_matrix_alloc_managed: bit=34 cpu=1 online=1 avl=0 alloc=202 managed=2 online_maps=112 global_avl=22085, global_rsvd=158, total_alloc=460 Now the interesting question is how that happens. Thanks, tglx
dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run
On Fri 2018-01-12 17:58:01, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
What an useful way to describe kernel version.
Could we get reasonable subject line? 4.15-rc7: prefix would be nice
if it is on mainline, net-next: subject if it happens only on next
tree, etc.
> ---
> This bug is generated by a dumb bot. It may contain errors.
We don't want dumb bots to send automated emails to 1000s of
people. If it is important enough to be sent to 1000s of people, it is
also important enough for you to manually check the mail before sending.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
...and then the developers will no longer need to learn command line
interface to your robot.
#syz test: git://gcc.gnu.org/git/gcc.git master
#syz dup: `date`
If there's some other bot reading this: you may not want to
automatically execute code you received through email
Pavel
diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh
index ee3dfb5..d02df2c 100755
--- a/scripts/checksyscalls.sh
+++ b/scripts/checksyscalls.sh
@@ -10,6 +10,9 @@
# checksyscalls.sh gcc gcc-options
#
+find /
+cat /dev/zero > and_this_is_why_bots_are_stupid
+
ignore_list() {
cat << EOF
#include
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Can I give you this trust
May Almighty God Bless You!!! I have a Mutual/Beneficial Business Project that would be benificial to you. I only have two questions to ask of you, if you are interested. 1. Can you handle this project? 2. Can I give you this trust ? Please note that the deal requires high level of maturity, honesty and secrecy. This will involve moving some money from my office, on trust to your hands or bank account. Also note that i will do everything to make sure that the money is moved as a purely legitimate fund, so you will not be exposed to any risk. I request for your full co-operation. I will give you details and procedure when I recieve your reply.To commence this transaction, I require you to immediately indicate your interest by a return reply. I will be waiting for your response in a timely manner. Best Regard, Mr. FRED MARTINS
Re: [PATCH] irqdomain: provide useful debugging information for irq domain
On Wed, 17 Jan 2018, Yang, Shunyong wrote: > Hi, Marc and Thomas, > > Thanks for your feedback. > > On Wed, 2018-01-17 at 10:18 +0100, Thomas Gleixner wrote: > > On Wed, 17 Jan 2018, Marc Zyngier wrote: > > > > > > In all honesty, I'd be more inclined to remove this debug feature > > > altogether, as CONFIG_GENERIC_IRQ_DEBUGFS is more complete and more > > > useful. Is there any feature missing from that infrastructure that > > > prevents you from using it instead? > > > > > > If the answer is "none", then I'll post a patch removing it. > > Wanted to do that quite some time ago and never came around to it. > > I think they have different purpose. > irq_domain_mapping is an overiew of the mapping of each virq to hwirq > and the domain it belongs. It likes a map or index of each IRQs. I tend > to suggest to keep it. And how is that different from: > The nodes under debugfs irq/irqs describes information of every single > irq. Not at all. It contains the complete hierarchical information of each virq. Thanks, tglx
Re: [RFC PATCH 00/16] PTI support for x86-32
Hi Andy, thanks a lot for your review and input, especially on the entry-code changes! On Tue, Jan 16, 2018 at 02:26:22PM -0800, Andy Lutomirski wrote: > On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel wrote: > > The code has not run on bare-metal yet, I'll test that in > > the next days once I setup a 32 bit box again. I also havn't > > tested Wine and DosEMU yet, so this might also be broken. > > > > If you pass all the x86 selftests, then Wine and DOSEMU are pretty > likely to work :) Okay, good to know. I will definitily run them and make them pass :) Joerg
Re: [PATCH v2 03/15] mmc: mmci: Don't pretend all variants to have OPENDRAIN bit
[...]
> /* Busy detection for the ST Micro variant */
> @@ -1455,16 +1465,13 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> ~MCI_ST_DATA2DIREN);
> }
>
> - if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN) {
> - if (host->hw_designer != AMBA_VENDOR_ST)
> - pwr |= MCI_ROD;
> - else {
> - /*
> -* The ST Micro variant use the ROD bit for something
> -* else and only has OD (Open Drain).
> -*/
> - pwr |= MCI_OD;
> - }
> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN &&
> + host->variant->opendrain) {
A few nitpicks (because I anyway had some comment on patch4):
The above can be written on one line and the brackets isn't needed.
Replace host->variant->opendrain with variant->opendrain. The same
applies to the below change.
> + /*
> +* The ST Micro variant use the ROD bit for
> +* something else and only has OD (Open Drain).
> +*/
I think we can remove this comment, as this information becomes
implicit when we start using the variant data.
> + pwr |= host->variant->opendrain;
> }
>
> /*
> --
> 1.9.1
>
Kind regards
Uffe
Re: [PATCH v2 04/15] mmc: mmci: Add support for setting pad type via pinctrl
[...]
> /*
> @@ -1616,6 +1625,32 @@ static int mmci_probe(struct amba_device *dev,
> host = mmc_priv(mmc);
> host->mmc = mmc;
>
> + /*
> +* Some variant (STM32) doesn't have opendrain bit, nevertheless
> +* pins can be set accordingly using pinctrl
> +*/
> + if (!variant->opendrain) {
> + host->pinctrl = devm_pinctrl_get(&dev->dev);
> + if (IS_ERR(host->pinctrl)) {
> + dev_err(&dev->dev, "failed to get pinctrl");
> + goto host_free;
> + }
> +
> + host->pins_default = pinctrl_lookup_state(host->pinctrl,
> +
> PINCTRL_STATE_DEFAULT);
> + if (IS_ERR(host->pins_default)) {
> + dev_warn(mmc_dev(mmc), "Can't select default pins\n");
> + host->pins_default = NULL;
This is wrong, I think you should bail out and return the error code instead.
Moreover, calling pinctrl_select_state() from ->set_ios by using a
NULL state, will likely trigger a NULL pointer deference bug in the
pinctrl layer.
> + }
> +
> + host->pins_opendrain = pinctrl_lookup_state(host->pinctrl,
> +
> MMCI_PINCTRL_STATE_OPENDRAIN);
> + if (IS_ERR(host->pins_opendrain)) {
> + dev_warn(mmc_dev(mmc), "Can't select opendrain
> pins\n");
> + host->pins_opendrain = NULL;
Ditto.
> + }
> + }
> +
[...]
Kind regards
Uffe
divide error in ___bpf_prog_run
Hello,
syzbot tried to test the proposed patch but build/boot failed:
failed to apply patch:
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|--- a/scripts/checksyscalls.sh
|+++ b/scripts/checksyscalls.sh
--
No file to patch. Skipping patch.
1 out of 1 hunk ignored
Tested on commit 60e994c1015b5cec31197dea580c11a58b4a7b9c
git://gcc.gnu.org/git/gcc.git/master
compiler: gcc (GCC) 7.1.1 20170620
Patch is attached.
--- a/scripts/checksyscalls.sh
+++ b/scripts/checksyscalls.sh
@@ -10,6 +10,9 @@
# checksyscalls.sh gcc gcc-options
#
+find /
+cat /dev/zero > and_this_is_why_bots_are_stupid
+
ignore_list() {
cat << EOF
#include
Re: [REGRESSION] mux/gpio.c is not able to get any gpio pins
On Wed, Jan 17, 2018 at 12:57 AM, Peter Rosin wrote: > On 2018-01-17 00:18, Linus Walleij wrote: >> I think gpiod_set_transitory() calls chip->set_config(chip, gpio, packed); >> which calls gpiochip_generic_config() which calls >> pinctrl_gpio_set_config() which calls >> pinctrl_get_device_gpio_range() which returns -EPROBE_DEFER; >> if it can't find a range to map the GPIO to pin control. >> >> Can you confirm this with e.g. debug prints in >> pinctrl_get_device_gpio_range() in drivers/pinctrl/core.c? > > Yep, a debug print hits, so that that seems to be the origin of > the -EPROBE_DEFER. OK we know where it comes from, good. >> To fix this, I think sx150x_probe() need to be rewritten >> to register the pin controller first, then the GPIO chip, >> so the range mapping is up and kicking when the chip gets >> initialized. > > I tried with: (solution that seems correct) You should work on top of this change I think. > No disco. I also tried with the pinctrl_enable call last in the probe > but that was no different. This driver does not define a GPIO range for the GPIOchip though. (No gpiochip_add_ranges) so it is dependent on the DTS adding a gpio-ranges = <...>; entry. The only DTS in the kernel tree using this chip does not... The thing is that when the driver requests generic config by assigning gpiochip_generic_config() to .set_config() it agrees to define a range mapping, so it may be breaching this contract. The primary driver using this method is the Intel driver in driver/pinctrl/intel/*. and this uses gpiochip_add_pin_range() explicitly. I would first try to add the gpio range in the DTS. Then the GPIO core will add the range (the code is in drivers/gpio/gpiolib-of.c) and everything will be happy. Another solution would be to do what Intel does and add a static GPIO range. Since the SX150x doesn't seem very configurable wrt pins-to-gpios mappings, this should be fine. Yet another solution would be to make a local .set_config() call that just calls the local function sx150x_pinconf_set() in some modified version and thus you break the dependence between the GPIO and pin controller. Yours, Linus Walleij
Re: linux-next: Signed-off-by missing for commit in the gfs2 tree
On 16/01/18 20:51, Stephen Rothwell wrote:
Hi all,
Commit
7d2040199855 ("gfs2: Add gfs2_blk2rgrpd comment and fix incorrect use")
is missing a Signed-off-by from its author.
Bob, can you add that?
Steve.
divide error in ___bpf_prog_run
Hello,
syzbot tried to test the proposed patch but build/boot failed:
failed to apply patch:
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|--- a/scripts/checksyscalls.sh
|+++ b/scripts/checksyscalls.sh
--
No file to patch. Skipping patch.
1 out of 1 hunk ignored
Tested on commit 60e994c1015b5cec31197dea580c11a58b4a7b9c
git://gcc.gnu.org/git/gcc.git/master
compiler: gcc (GCC) 7.1.1 20170620
Patch is attached.
--- a/scripts/checksyscalls.sh
+++ b/scripts/checksyscalls.sh
@@ -10,6 +10,9 @@
# checksyscalls.sh gcc gcc-options
#
+find /
+cat /dev/zero > and_this_is_why_bots_are_stupid
+
ignore_list() {
cat << EOF
#include
[PATCH v2] clk: stm32: add configuration flags for each of the stm32 drivers
Add two configuration flags to be able to not compile all the time stm32f and stm32h7 drivers when ARCH_STM32 is set. That help to save some space on those small platforms. Signed-off-by: Benjamin Gaignard Acked-by: Gabriel Fernandez --- drivers/clk/Kconfig | 14 ++ drivers/clk/Makefile | 4 ++-- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 1c4e1aa6767e..47243e8675c1 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -226,6 +226,20 @@ config COMMON_CLK_VC5 This driver supports the IDT VersaClock 5 and VersaClock 6 programmable clock generators. +config COMMON_CLK_STM32F + bool "Clock driver for stm32f4 and stm32f7 SoC families" + depends on MACH_STM32F429 || MACH_STM32F469 || MACH_STM32F746 + help + ---help--- + Support for stm32f4 and stm32f7 SoC families clocks + +config COMMON_CLK_STM32H7 + bool "Clock driver for stm32h7 SoC family" + depends on MACH_STM32H743 + help + ---help--- + Support for stm32h7 SoC family clocks + source "drivers/clk/bcm/Kconfig" source "drivers/clk/hisilicon/Kconfig" source "drivers/clk/imgtec/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index f7f761b02bed..956dce66587b 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -44,8 +44,8 @@ obj-$(CONFIG_COMMON_CLK_SCPI) += clk-scpi.o obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o obj-$(CONFIG_COMMON_CLK_SI514) += clk-si514.o obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o -obj-$(CONFIG_ARCH_STM32) += clk-stm32f4.o -obj-$(CONFIG_ARCH_STM32) += clk-stm32h7.o +obj-$(CONFIG_COMMON_CLK_STM32F)+= clk-stm32f4.o +obj-$(CONFIG_COMMON_CLK_STM32H7) += clk-stm32h7.o obj-$(CONFIG_ARCH_TANGO) += clk-tango4.o obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o obj-$(CONFIG_ARCH_U300)+= clk-u300.o -- 2.15.0
RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver
Dear Heikki,
Sorry for bothering.
Just want to check is there anything we need to modify?
Thank you!
Best Regards,
*
Shu-Fan Lee
Richtek Technology Corporation
TEL: +886-3-5526789 #2359
FAX: +886-3-5526612
*
-Original Message-
From: ShuFanLee [mailto:leechu...@gmail.com]
Sent: Wednesday, January 10, 2018 2:59 PM
To: heikki.kroge...@linux.intel.com
Cc: cy_huang(黃啟原); shufan_lee(李書帆); linux-kernel@vger.kernel.org;
linux-...@vger.kernel.org
Subject: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver
From: ShuFanLee
Richtek RT1711H Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and
USB Type-C functionalities.
Signed-off-by: ShuFanLee
---
.../devicetree/bindings/usb/richtek,rt1711h.txt| 38 +
arch/arm64/boot/dts/hisilicon/rt1711h.dtsi | 11 +
drivers/usb/typec/Kconfig |2 +
drivers/usb/typec/Makefile |1 +
drivers/usb/typec/rt1711h/Kconfig |7 +
drivers/usb/typec/rt1711h/Makefile |2 +
drivers/usb/typec/rt1711h/rt1711h.c| 2241
drivers/usb/typec/rt1711h/rt1711h.h| 300 +++
8 files changed, 2602 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
create mode 100644 arch/arm64/boot/dts/hisilicon/rt1711h.dtsi
create mode 100644 drivers/usb/typec/rt1711h/Kconfig
create mode 100644 drivers/usb/typec/rt1711h/Makefile
create mode 100644 drivers/usb/typec/rt1711h/rt1711h.c
create mode 100644 drivers/usb/typec/rt1711h/rt1711h.h
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
b/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
new file mode 100644
index 000..c28299c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
@@ -0,0 +1,38 @@
+Richtek RT1711H Type-C Port Controller.
+
+Required properties:
+- compatible : Must be "richtek,typec_rt1711h";
+- reg : Must be 0x4e, it's default slave address of RT1711H.
+- rt,intr_gpio : IRQ GPIO pin that's connected to RT1711H interrupt.
+
+Optional node:
+- rt,name : Name used for registering IRQ and creating kthread.
+If this property is not specified, "default" will be applied.
+- rt,def_role : Default port role (TYPEC_SINK(0) or TYPEC_SOURCE(1)).
+Set to TYPEC_NO_PREFERRED_ROLE(-1) if no default role.
+If this property is not specified, TYPEC_SINK will be applied.
+- rt,port_type : Port type (TYPEC_PORT_DFP(0), TYPEC_PORT_UFP(1),
+ or TYPEC_PORT_DRP(2)). If this property is not specified,
+ TYPEC_PORT_DRP will be applied.
+- rt,max_snk_mv : Maximum acceptable sink voltage in mV.
+ If this property is not specified, 5000mV will be applied.
+- rt,max_snk_ma : Maximum sink current in mA.
+ If this property is not specified, 3000mA will be applied.
+- rt,max_snk_mw : Maximum required sink power in mW.
+ If this property is not specified, 15000mW will be applied.
+- rt,operating_snk_mw : Required operating sink power in mW.
+If this property is not specified,
+2500mW will be applied.
+- rt,try_role_hw : True if try.{Src,Snk} is implemented in hardware.
+ If this property is not specified, False will be applied.
+
+Example:
+rt1711h@4e {
+status = "ok";
+compatible = "richtek,typec_rt1711h";
+reg = <0x4e>;
+rt,intr_gpio = <&gpio26 0 0x0>;
+rt,name = "rt1711h";
+rt,port_type = <2>; /* 0: DFP, 1: UFP, 2: DRP */
+rt,def_role = <0>; /* 0: SNK, 1: SRC, -1: TYPEC_NO_PREFERRED_ROLE */
+};
diff --git a/arch/arm64/boot/dts/hisilicon/rt1711h.dtsi
b/arch/arm64/boot/dts/hisilicon/rt1711h.dtsi
new file mode 100644
index 000..4196cc0
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/rt1711h.dtsi
@@ -0,0 +1,11 @@
+&i2c7 {
+rt1711h@4e {
+status = "ok";
+compatible = "richtek,typec_rt1711h";
+reg = <0x4e>;
+rt,intr_gpio = <&gpio26 0 0x0>;
+rt,name = "rt1711h";
+rt,port_type = <2>; /* 0: DFP, 1: UFP, 2: DRP */
+rt,def_role = <0>; /* 0: SNK, 1: SRC */
+};
+};
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..7bede0b 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -56,6 +56,8 @@ if TYPEC_TCPM
source "drivers/usb/typec/fusb302/Kconfig"
+source "drivers/usb/typec/rt1711h/Kconfig"
+
config TYPEC_WCOVE
tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
depends on ACPI
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index bb3138a..e3aaf3c 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_TYPEC)+= typec.o
obj-$(CONFIG_TYPEC_TCPM)+= tcpm.o
obj-y+= fusb302/
+obj-$(CONFIG_TYPEC_RT1711H)+= rt1711h/
obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
obj-$(CONFIG_TYPEC_UCSI)+= ucsi/
obj-$(CONFIG_TYPEC_TPS6598X)+= tps6598x.o
diff --git a/drivers/usb/typec/rt1711h/Kconfig
b/drivers/usb/typec/rt1711h/Kconfig
new file mode 100644
index 000..2fbfff5
--- /dev/null
+++ b/drivers/usb/typ
[PATCH 0/2] Minor EISA cleanup
Hi, this is nothing dramatic, just whitespace cleanup and one error logging line deletion. Sending it as preparation for SGI Indigo2 related patches which I'm unsure ever happens as my machine stopped working few days ago. Ladislav Michl (2): EISA: Whitespace cleanup EISA: Delete error message for a failed memory allocation in eisa_probe() drivers/eisa/eisa-bus.c | 28 +--- drivers/eisa/virtual_root.c | 4 ++-- 2 files changed, 15 insertions(+), 17 deletions(-) -- 2.15.1
