Re: [PATCH v2] kbuild: check the minimum compiler version in Kconfig
Hi Masahiro, > + #elif defined(__INTEL_COMPILER) > + /* How to get the version of intel compiler? */ > + ICC 0 0 0 According to Intel documentation[1], this should do the trick: ICC __INTEL_COMPILER __INTEL_COMPILER_UPDATE __INTEL_COMPILER_BUILD_DATE I don't have the compiler installed, but I tested this on godbolt[2] and looks fine to me. What do you think? [1] https://software.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/macros/additional-predefined-macros.html [2] https://godbolt.org/z/E5PE6f I.H.
[PATCH 03/10] KVM: x86: hyper-v: add a blank line to remove building warnings
.../Documentation/virt/kvm/api.rst:4536: WARNING: Unexpected indentation.
.../Documentation/virt/kvm/api.rst:4538: WARNING: Block quote ends without a
blank line; unexpected unindent.
Fixes: c21d54f0307f ("KVM: x86: hyper-v: allow KVM_GET_SUPPORTED_HV_CPUID as a
system ioctl")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/virt/kvm/api.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index c136e254b496..c95572a66a7b 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -4532,6 +4532,7 @@ userspace should not expect to get any particular value
there.
Note, vcpu version of KVM_GET_SUPPORTED_HV_CPUID is currently deprecated.
Unlike
system ioctl which exposes all supported feature bits unconditionally, vcpu
version has the following quirks:
+
- HYPERV_CPUID_NESTED_FEATURES leaf and HV_X64_ENLIGHTENED_VMCS_RECOMMENDED
feature bit are only exposed when Enlightened VMCS was previously enabled
on the corresponding vCPU (KVM_CAP_HYPERV_ENLIGHTENED_VMCS).
--
2.29.2
[PATCH 01/10] doc/zh_CN: fix Sphinx errors
The whitespacing with some translations are weird, which causes errors like this one: devel/v4l/docs/Documentation/translations/zh_CN/mips/ingenic-tcu.rst:61: WARNING: Malformed table. Text in column margin in table line 6. === = 时钟drivers/clk/ingenic/tcu.c 中断drivers/irqchip/irq-ingenic-tcu.c 定时器 drivers/clocksource/ingenic-timer.c OST drivers/clocksource/ingenic-ost.c 脉冲宽度调制器 drivers/pwm/pwm-jz4740.c 看门狗 drivers/watchdog/jz4740_wdt.c === = Fix it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst index 72b5d409ed89..919ae1d4734e 100644 --- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst +++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst @@ -53,14 +53,14 @@ TCU硬件的功能分布在多个驱动程序： -=== = +== === 时钟drivers/clk/ingenic/tcu.c 中断drivers/irqchip/irq-ingenic-tcu.c 定时器 drivers/clocksource/ingenic-timer.c OST drivers/clocksource/ingenic-ost.c 脉冲宽度调制器 drivers/pwm/pwm-jz4740.c 看门狗 drivers/watchdog/jz4740_wdt.c -=== = +== === 因为可以从相同的寄存器控制属于不同驱动程序和框架的TCU的各种功能，所以 所有这些驱动程序都通过相同的控制总线通用接口访问它们的寄存器。 -- 2.29.2
[PATCH 09/10] media: v4l2-subdev.rst: fix a missing whitespace
Solves this warning: .../Documentation/driver-api/media/v4l2-subdev.rst:125: WARNING: Inline interpreted text or phrase reference start-string without end-string. Signed-off-by: Mauro Carvalho Chehab --- Documentation/driver-api/media/v4l2-subdev.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 6d5c799c49fe..0e82c77cf3e2 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -123,7 +123,7 @@ Don't forget to cleanup the media entity before the sub-device is destroyed: media_entity_cleanup(>entity); If a sub-device driver implements sink pads, the subdev driver may set the -link_validate field in :c:type:`v4l2_subdev_pad_ops`to provide its own link +link_validate field in :c:type:`v4l2_subdev_pad_ops` to provide its own link validation function. For every link in the pipeline, the link_validate pad operation of the sink end of the link is called. In both cases the driver is still responsible for validating the correctness of the format configuration -- 2.29.2
[PATCH 08/10] doc: zh_CN/mips: fix doc cross-references
There are several wrong references there: .../Documentation/translations/zh_CN/mips/booting.rst:5: WARNING: undefined label: booting (if the link has no caption the label must precede a section header) .../Documentation/translations/zh_CN/mips/features.rst:5: WARNING: undefined label: features (if the link has no caption the label must precede a section header) .../Documentation/translations/zh_CN/mips/index.rst:5: WARNING: undefined label: index (if the link has no caption the label must precede a section header) .../Documentation/translations/zh_CN/mips/ingenic-tcu.rst:5: WARNING: undefined label: ingenic-tcu (if the link has no caption the label must precede a section header) Replace them by :doc: markup, which won't require to add anything extra at the existing documents. Signed-off-by: Mauro Carvalho Chehab --- Documentation/translations/zh_CN/mips/booting.rst | 2 +- Documentation/translations/zh_CN/mips/features.rst| 2 +- Documentation/translations/zh_CN/mips/index.rst | 2 +- Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/translations/zh_CN/mips/booting.rst b/Documentation/translations/zh_CN/mips/booting.rst index 3099d0fff7a6..00bebf7681f9 100644 --- a/Documentation/translations/zh_CN/mips/booting.rst +++ b/Documentation/translations/zh_CN/mips/booting.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/booting.rst ` +:Original: :doc:`/mips/booting` :Translator: Yanteng Si .. _cn_booting: diff --git a/Documentation/translations/zh_CN/mips/features.rst b/Documentation/translations/zh_CN/mips/features.rst index 7e67f81a0982..72adcd9b360f 100644 --- a/Documentation/translations/zh_CN/mips/features.rst +++ b/Documentation/translations/zh_CN/mips/features.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/features.rst ` +:Original: :doc:`/mips/features` :Translator: Yanteng Si .. _cn_features: diff --git a/Documentation/translations/zh_CN/mips/index.rst b/Documentation/translations/zh_CN/mips/index.rst index 2c7b836a3da5..c2ab89890979 100644 --- a/Documentation/translations/zh_CN/mips/index.rst +++ b/Documentation/translations/zh_CN/mips/index.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/index.rst ` +:Original: :doc:`/mips/index` :Translator: Yanteng Si .. _cn_index: diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst index 919ae1d4734e..cb570d7eca24 100644 --- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst +++ b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/mips/ingenic-tcu.rst ` +:Original: :doc:`/mips/ingenic-tcu` :Translator: Yanteng Si .. _cn_ingenic-tcu: -- 2.29.2
[PATCH 02/10] ABI: sysfs-fs-f2fs: fix a table identation
Solves this doc build error:
.../Documentation/ABI/testing/sysfs-fs-f2fs:382: WARNING: Malformed table.
Text in column margin in table line 15.
= = =
value sb status macro description
0x1SBI_IS_DIRTY dirty flag for checkpoint
0x2SBI_IS_CLOSE specify unmounting
0x4SBI_NEED_FSCK need fsck.f2fs to fix
0x8SBI_POR_DOING recovery is doing or not
0x10 SBI_NEED_SB_WRITE need to recover superblock
0x20 SBI_NEED_CP need to checkpoint
0x40 SBI_IS_SHUTDOWN shutdown by ioctl
0x80 SBI_IS_RECOVERED recovered orphan/data
0x100 SBI_CP_DISABLED CP was disabled last mount
0x200 SBI_CP_DISABLED_QUICK CP was disabled quickly
0x400 SBI_QUOTA_NEED_FLUSH need to flush quota info in CP
0x800 SBI_QUOTA_SKIP_FLUSH skip flushing quota in current CP
0x1000 SBI_QUOTA_NEED_REPAIR quota file may be corrupted
0x2000 SBI_IS_RESIZEFS resizefs is in process
== = =
Fixes: 969945899a35 ("f2fs: introduce sb_status sysfs node")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/testing/sysfs-fs-f2fs | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index e5918c93f3bf..1ba8d533437a 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -383,8 +383,9 @@ Date: December 2020
Contact: "Chao Yu"
Description: Show status of f2fs superblock in real time.
- = = =
+ == = =
value sb status macro description
+ == = =
0x1SBI_IS_DIRTY dirty flag for checkpoint
0x2SBI_IS_CLOSE specify unmounting
0x4SBI_NEED_FSCK need fsck.f2fs to fix
--
2.29.2
[PATCH 04/10] ABI: sysfs-firmware-sgi_uv
Add a missing blank line required to identify a literal block,
fixing this warning:
.../Documentation/ABI/testing/sysfs-firmware-sgi_uv:2: WARNING:
Unexpected indentation.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/testing/sysfs-firmware-sgi_uv | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
index 637c668cbe45..b0f79a1d14b3 100644
--- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
+++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
@@ -39,6 +39,7 @@ Description:
The uv_type entry contains the hub revision number.
This value can be used to identify the UV system version::
+
"0.*" = Hubless UV ('*' is subtype)
"3.0" = UV2
--
2.29.2
[PATCH 06/10] drm: amd: amdgpu_dm.h: fix a wrong kernel-doc markup
There's a missing colon, causing the markup to be ignored,
solving those warnings:
../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:340: warning:
Incorrect use of kernel-doc format: * @active_vblank_irq_count
../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:379: warning:
Function parameter or member 'active_vblank_irq_count' not described in
'amdgpu_display_manager'
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index f084e2fc9569..5ee1b766884e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -337,7 +337,7 @@ struct amdgpu_display_manager {
const struct gpu_info_soc_bounding_box_v1_0 *soc_bounding_box;
/**
-* @active_vblank_irq_count
+* @active_vblank_irq_count:
*
* number of currently active vblank irqs
*/
--
2.29.2
[PATCH 10/10] seqlock: kernel-doc: fix a prototype
Right now, kernel-doc produces a warning:
./include/linux/seqlock.h:829: warning: wrong kernel-doc identifier on
line:
* DEFINE_SEQLOCK(sl) - Define a statically allocated seqlock_t
The issue is that Kernel-doc valid syntaxes for function/define
declarations are either:
function_foo - description
or:
function_foo() - description
The function parameters should be declared only afterwards.
So, replace it to:
DEFINE_SEQLOCK(sl) - Define a statically allocated seqlock_t
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/seqlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 2f7bb92b4c9e..209454cedf61 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -826,7 +826,7 @@ typedef struct {
} while (0)
/**
- * DEFINE_SEQLOCK(sl) - Define a statically allocated seqlock_t
+ * DEFINE_SEQLOCK() - Define a statically allocated seqlock_t
* @sl: Name of the seqlock_t instance
*/
#define DEFINE_SEQLOCK(sl) \
--
2.29.2
[PATCH 07/10] dwc3: document gadget_max_speed
This new field was added to struct dwc3_scratchpad_array, but
a documentation for it was missed:
../drivers/usb/dwc3/core.h:1259: warning: Function parameter or member
'gadget_max_speed' not described in 'dwc3'
Signed-off-by: Mauro Carvalho Chehab
---
drivers/usb/dwc3/core.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index ac290d896638..eec1cf4ba268 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -964,6 +964,7 @@ struct dwc3_scratchpad_array {
* @nr_scratch: number of scratch buffers
* @u1u2: only used on revisions <1.83a for workaround
* @maximum_speed: maximum speed requested (mainly for testing purposes)
+ * @gadget_max_speed: maximum gadget speed requested
* @ip: controller's ID
* @revision: controller's version of an IP
* @version_type: VERSIONTYPE register contents, a sub release of a revision
--
2.29.2
[PATCH 00/10] Fix documentation warnings at linux-next
This series fixes the documentation warnings found at next-20210114. Most of the changes here are trivial. While those patches could be merged via the docs tree during the next merge window, It sounds better to have those patches merged directly via each maintainer's tree, where the new warnings were introduced. Regards, Mauro Mauro Carvalho Chehab (10): doc/zh_CN: fix Sphinx errors ABI: sysfs-fs-f2fs: fix a table identation KVM: x86: hyper-v: add a blank line to remove building warnings ABI: sysfs-firmware-sgi_uv docs: fpga: dfl.rst: Fix a couple building issues drm: amd: amdgpu_dm.h: fix a wrong kernel-doc markup dwc3: document gadget_max_speed doc: zh_CN/mips: fix doc cross-references media: v4l2-subdev.rst: fix a missing whitespace seqlock: kernel-doc: fix a prototype Documentation/ABI/testing/sysfs-firmware-sgi_uv | 1 + Documentation/ABI/testing/sysfs-fs-f2fs | 3 ++- Documentation/driver-api/media/v4l2-subdev.rst| 2 +- Documentation/fpga/dfl.rst| 4 ++-- Documentation/translations/zh_CN/mips/booting.rst | 2 +- Documentation/translations/zh_CN/mips/features.rst| 2 +- Documentation/translations/zh_CN/mips/index.rst | 2 +- Documentation/translations/zh_CN/mips/ingenic-tcu.rst | 6 +++--- Documentation/virt/kvm/api.rst| 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +- drivers/usb/dwc3/core.h | 1 + include/linux/seqlock.h | 2 +- 12 files changed, 16 insertions(+), 12 deletions(-) -- 2.29.2
[PATCH 05/10] docs: fpga: dfl.rst: Fix a couple building issues
A title markup length is smaller than required; A literal block is not marked as such. This fixes the warnings below: .../Documentation/fpga/dfl.rst:505: WARNING: Title underline too short. Location of DFLs on a PCI Device === .../Documentation/fpga/dfl.rst:523: WARNING: Unexpected indentation. .../Documentation/fpga/dfl.rst:523: WARNING: Blank line required after table. .../Documentation/fpga/dfl.rst:524: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab --- Documentation/fpga/dfl.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index ea8cefc18bdb..716a3d705046 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -502,7 +502,7 @@ FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c) could be a reference. Location of DFLs on a PCI Device -=== + The original method for finding a DFL on a PCI device assumed the start of the first DFL to offset 0 of bar 0. If the first node of the DFL is an FME, then further DFLs in the port(s) are specified in FME header registers. @@ -513,7 +513,7 @@ VSEC ID of 0x43 for this purpose. The vendor specific data begins with a 4 byte vendor specific register for the number of DFLs followed 4 byte Offset/BIR vendor specific registers for each DFL. Bits 2:0 of Offset/BIR register indicates the BAR, and bits 31:3 form the 8 byte aligned offset where bits 2:0 are -zero. +zero:: ++ |31 Number of DFLS 0| -- 2.29.2
Re: [PATCH v7 3/7] fixup! media: i2c: rdacm21: Break-out ov10640 initialization
Hi Laurent,
On Thu, Jan 14, 2021 at 01:23:25AM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wed, Jan 13, 2021 at 07:55:01PM +0100, Jacopo Mondi wrote:
> > The embedded OV490 ISP chip provides a secondary SCCB interface and
> > two GPIO lines to control the connected OV10640 image sensor.
> >
> > Break out the OV10640 initialization from the OV490 initialization and
> > explicitely control the powerdown and reset GPIOs. After the image
>
> s/explicitely/explicitly/
>
> > sensor has been hard reset, implement a more clear handling of the
> > secondary SCCB interface to read the image sensor chip ID.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/media/i2c/rdacm21.c | 75 ++---
> > 1 file changed, 61 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c
> > index 0428e3209463..944009687de5 100644
> > --- a/drivers/media/i2c/rdacm21.c
> > +++ b/drivers/media/i2c/rdacm21.c
> > @@ -30,11 +30,24 @@
> > #define OV490_PAGE_HIGH_REG0xfffd
> > #define OV490_PAGE_LOW_REG 0xfffe
> >
> > +/*
> > + * The SCCB slave handling is undocumented; the registers naming scheme is
> > + * totally arbitrary.
> > + */
> > +#define OV490_SCCB_SLAVE_WRITE 0x00
> > +#define OV490_SCCB_SLAVE_READ 0x01
> > +#define OV490_SCCB_SLAVE0_DIR 0x80195000
> > +#define OV490_SCCB_SLAVE0_ADDR_HIGH0x80195001
> > +#define OV490_SCCB_SLAVE0_ADDR_LOW 0x80195002
> > +
> > #define OV490_DVP_CTRL30x80286009
> >
> > #define OV490_ODS_CTRL_FRAME_OUTPUT_EN 0x0c
> > #define OV490_ODS_CTRL 0x8029d000
> >
> > +#define OV490_HOST_CMD 0x808000c0
> > +#define OV490_HOST_CMD_TRIGGER 0xc1
> > +
> > #define OV490_ID_VAL 0x0490
> > #define OV490_ID(_p, _v) _p) & 0xff) << 8) | ((_v) & 0xff))
> > #define OV490_PID 0x8080300a
> > @@ -42,12 +55,22 @@
> > #define OV490_PID_TIMEOUT 20
> > #define OV490_OUTPUT_EN_TIMEOUT300
> >
> > +#define OV490_GPIO0_RESETB 0x01
>
> Shouldn't this be named just OV490_GPIO0 ? The fact that it's connected
> to the RESETB signal of the OV10640 is board-specific, not an OV490
> intrinsic property.
>
> BIT(0) ?
>
> > +#define OV490_SPWDN0 0x01
>
> Same here.
>
Correct, I'll fix...
> > +#define OV490_GPIO_SEL00x80800050
> > +#define OV490_GPIO_SEL10x80800051
> > +#define OV490_GPIO_DIRECTION0 0x80800054
> > +#define OV490_GPIO_DIRECTION1 0x80800055
> > +#define OV490_GPIO_OUTPUT_VALUE0 0x80800058
> > +#define OV490_GPIO_OUTPUT_VALUE1 0x80800059
> > +
> > #define OV490_ISP_HSIZE_LOW0x80820060
> > #define OV490_ISP_HSIZE_HIGH 0x80820061
> > #define OV490_ISP_VSIZE_LOW0x80820062
> > #define OV490_ISP_VSIZE_HIGH 0x80820063
> >
> > -#define OV10640_ID_LOW 0xa6
> > +#define OV10640_ID_HIGH0xa6
> > +#define OV10640_CHIP_ID0x300a
> > #define OV10640_PIXEL_RATE 5500
> >
> > struct rdacm21_device {
> > @@ -306,6 +329,39 @@ static const struct v4l2_subdev_ops rdacm21_subdev_ops
> > = {
> > .pad= _subdev_pad_ops,
> > };
> >
> > +static int ov10640_initialize(struct rdacm21_device *dev)
> > +{
> > + u8 val;
> > +
> > + /* Power-up OV10640 by setting RESETB and PWDNB pins high. */
> > + ov490_write_reg(dev, OV490_GPIO_SEL0, OV490_GPIO0_RESETB);
> > + ov490_write_reg(dev, OV490_GPIO_SEL1, OV490_SPWDN0);
> > + ov490_write_reg(dev, OV490_GPIO_DIRECTION0, OV490_GPIO0_RESETB);
> > + ov490_write_reg(dev, OV490_GPIO_DIRECTION1, OV490_SPWDN0);
> > + ov490_write_reg(dev, OV490_GPIO_OUTPUT_VALUE0, OV490_GPIO0_RESETB);
> > + ov490_write_reg(dev, OV490_GPIO_OUTPUT_VALUE0, OV490_SPWDN0);
> > + usleep_range(3000, 5000);
>
> So the OV490 firmware doesn't handle this ?
>
Do you mean the delay or the reset of the ov10640 ?
I need the delay here otherwise reading the ov10640 id fails below.
Same for the reset :)
About reset, it seems it does not... The ov490 settings are loaded
from an EEPROM but I don't know what it content is, maybe it's just
about the imaging-related settings ?
> > +
> > + /* Read OV10640 ID to test communications. */
> > + ov490_write_reg(dev, OV490_SCCB_SLAVE0_DIR, OV490_SCCB_SLAVE_READ);
> > + ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_HIGH, OV10640_CHIP_ID >> 8);
> > + ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_LOW, (u8)OV10640_CHIP_ID);
> > +
> > + /* Trigger SCCB slave transaction and give it some time to complete. */
> > + ov490_write_reg(dev, OV490_HOST_CMD, OV490_HOST_CMD_TRIGGER);
> > + usleep_range(1000, 1500);
> > +
> > + ov490_read_reg(dev, OV490_SCCB_SLAVE0_DIR, );
> > + if (val !=
Re: [PATCH 1/4] tracing: add error_report trace points
On Wed, Jan 13, 2021 at 10:10 PM Steven Rostedt wrote:
>
> On Wed, 13 Jan 2021 10:16:54 +0100
> Alexander Potapenko wrote:
>
> > +DECLARE_EVENT_CLASS(error_report_template,
> > + TP_PROTO(const char *error_detector, unsigned long id),
>
> Instead of having a random string, as this should be used by a small finite
> set of subsystems, why not make the above into an enum?
You're probably right.
I just thought it might be a good idea to minimize the effort needed
from tools' authors to add these tracepoints to the tools (see the
following two patches), and leave room for some extensibility (e.g.
passing bug type together with the tool name etc.)
> > + TP_ARGS(error_detector, id),
> > + TP_STRUCT__entry(__field(const char *, error_detector)
> > + __field(unsigned long, id)),
> > + TP_fast_assign(__entry->error_detector = error_detector;
> > +__entry->id = id;),
> > + TP_printk("[%s] %lx", __entry->error_detector,
>
> Then the [%s] portion of this could also be just a __print_symbolic().
We'll need to explicitly list the enum values once again in
__print_symbolic(), right? E.g.:
enum debugging_tool {
TOOL_KFENCE,
TOOL_KASAN,
...
}
TP_printk(__print_symbolic(__entry->error_detector, TOOL_KFENCE,
TOOL_KASAN, ...),
[PATCH net-next] net: bridge: use eth_type_vlan in br_dev_queue_push_xmit
From: Menglong Dong
Replace the check for ETH_P_8021Q and ETH_P_8021AD in
br_dev_queue_push_xmit with eth_type_vlan.
Signed-off-by: Menglong Dong
---
net/bridge/br_forward.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index e28ffadd1371..6e9b049ae521 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -39,8 +39,7 @@ int br_dev_queue_push_xmit(struct net *net, struct sock *sk,
struct sk_buff *skb
br_drop_fake_rtable(skb);
if (skb->ip_summed == CHECKSUM_PARTIAL &&
- (skb->protocol == htons(ETH_P_8021Q) ||
-skb->protocol == htons(ETH_P_8021AD))) {
+ eth_type_vlan(skb->protocol)) {
int depth;
if (!__vlan_get_protocol(skb, skb->protocol, ))
--
2.25.1
[PATCH v2 2/2] perf tools: Add documentation for 'perf irq' command
Add documentation for 'perf irq' command.
Signed-off-by: Bixuan Cui
---
tools/perf/Documentation/perf-irq.txt | 58 +++
tools/perf/command-list.txt | 1 +
2 files changed, 59 insertions(+)
create mode 100644 tools/perf/Documentation/perf-irq.txt
diff --git a/tools/perf/Documentation/perf-irq.txt
b/tools/perf/Documentation/perf-irq.txt
new file mode 100644
index ..22709b6df62d
--- /dev/null
+++ b/tools/perf/Documentation/perf-irq.txt
@@ -0,0 +1,58 @@
+perf-irq(1)
+=
+
+NAME
+
+perf-irq - Tool to trace/measure hardware interrupts
+
+SYNOPSIS
+
+[verse]
+'perf irq' {record|report|script}
+
+DESCRIPTION
+---
+There are several variants of 'perf irq':
+
+ 'perf irq record ' to record the irq handler events
+ of an arbitrary workload.
+
+ 'perf irq script' to see a detailed trace of the workload that
+ was recorded (aliased to 'perf script' for now).
+
+ 'perf irq report' to calculate the time consumed by each
+ hardware interrupt processing function.
+
+Example usage:
+perf irq record -- sleep 1
+perf irq report
+
+ By default it shows the individual irq events, including the irq name,
+ cpu(execute the hardware interrupt processing function), time consumed,
+ entry time and exit time for the each hardware irq:
+
+
---
+ Irq name | CPU | Time consume us | Handler entry time |
Handler exit time
+
---
+ enp2s0f2-tx-0| [0006] | 0.01 s | 6631263.313329 s |
6631263.313330 s
+
+
---
+ Irq name | CPU | Time consume us | Handler entry time |
Handler exit time
+
---
+ megasas | [0013] | 0.03 s | 6631263.209564 s |
6631263.209567 s
+
+
---
+ Irq name | CPU | Time consume us | Handler entry time |
Handler exit time
+
---
+ acpi | [0016] | 0.18 s | 6631263.085787 s |
6631263.085805 s
+
+
+OPTIONS for 'perf irq report'
+
+
+--cpus::
+ Show just entries with activities for the given CPUs.
+
+SEE ALSO
+
+linkperf:perf-record[1]
diff --git a/tools/perf/command-list.txt b/tools/perf/command-list.txt
index bc6c585f74fc..c5224ea3ac71 100644
--- a/tools/perf/command-list.txt
+++ b/tools/perf/command-list.txt
@@ -26,6 +26,7 @@ perf-report mainporcelain common
perf-sched mainporcelain common
perf-scriptmainporcelain common
perf-stat mainporcelain common
+perf-irq mainporcelain common
perf-test mainporcelain common
perf-timechart mainporcelain common
perf-top mainporcelain common
--
2.17.1
[PATCH v2 1/2] perf tools: add 'perf irq' to measure the hardware interrupts
Add 'perf irq' to trace/measure the hardware interrupts.
Now three functions are provided:
1. 'perf irq record ' to record the irq handler events.
2. 'perf irq script' to see a detailed trace of the workload that
was recorded.
3. 'perf irq report' to calculate the time consumed by each
hardware interrupt processing function.
Signed-off-by: Bixuan Cui
---
tools/perf/Build | 1 +
tools/perf/builtin-irq.c | 287 +++
tools/perf/builtin.h | 1 +
tools/perf/perf.c| 1 +
4 files changed, 290 insertions(+)
create mode 100644 tools/perf/builtin-irq.c
diff --git a/tools/perf/Build b/tools/perf/Build
index 5f392dbb88fc..d52a1e1d6d8a 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -24,6 +24,7 @@ perf-y += builtin-mem.o
perf-y += builtin-data.o
perf-y += builtin-version.o
perf-y += builtin-c2c.o
+perf-y += builtin-irq.o
perf-$(CONFIG_TRACE) += builtin-trace.o
perf-$(CONFIG_LIBELF) += builtin-probe.o
diff --git a/tools/perf/builtin-irq.c b/tools/perf/builtin-irq.c
new file mode 100644
index ..58dd1a488edf
--- /dev/null
+++ b/tools/perf/builtin-irq.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "builtin.h"
+#include "perf.h"
+#include "perf-sys.h"
+
+#include "util/cpumap.h"
+#include "util/evlist.h"
+#include "util/evsel.h"
+#include "util/evsel_fprintf.h"
+#include "util/symbol.h"
+#include "util/thread.h"
+#include "util/header.h"
+#include "util/session.h"
+#include "util/tool.h"
+#include "util/cloexec.h"
+#include "util/thread_map.h"
+#include "util/color.h"
+#include "util/stat.h"
+#include "util/string2.h"
+#include "util/callchain.h"
+#include "util/time-utils.h"
+
+#include
+#include
+#include "util/trace-event.h"
+
+#include "util/debug.h"
+#include "util/event.h"
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define IRQ_NAME_LEN 20
+#define MAX_CPUS 4096
+
+static const char *cpu_list;
+static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+
+struct perf_irq;
+
+struct perf_irq {
+ struct perf_tool tool;
+ bool force;
+
+ u32 irq_entry_irq;
+ char irq_name[IRQ_NAME_LEN];
+ u32 cpu;
+ u64 irq_entry_time;
+ u32 irq_entry_pid;
+ u32 irq_exit_irq;
+ u64 irq_exit_time;
+ u32 irq_exit_pid;
+};
+
+typedef int (*irq_handler)(struct perf_tool *tool,
+ union perf_event *event,
+ struct evsel *evsel,
+ struct perf_sample *sample,
+ struct machine *machine);
+
+static int perf_report_process_sample(struct perf_tool *tool,
+union perf_event *event,
+struct perf_sample *sample,
+struct evsel *evsel,
+struct machine *machine)
+{
+ int err = 0;
+
+ if (evsel->handler != NULL) {
+ irq_handler f = evsel->handler;
+ err = f(tool, event, evsel, sample, machine);
+ }
+
+ return err;
+}
+
+static void output_report(struct perf_irq *irq)
+{
+ int ret, i;
+ char irq_entry_time[30], irq_exit_time[30], irq_diff[30];
+
+ /* The entry and exit of the hardware irq function
+* exist at the same time. Check it by irq and pid.
+*/
+ if (irq->irq_entry_pid != irq->irq_exit_pid ||
+ irq->irq_entry_irq != irq->irq_exit_irq)
+ return;
+
+ timestamp__scnprintf_usec(irq->irq_entry_time,
+ irq_entry_time, sizeof(irq_entry_time));
+ timestamp__scnprintf_usec(irq->irq_exit_time,
+ irq_exit_time, sizeof(irq_exit_time));
+ timestamp__scnprintf_usec(irq->irq_exit_time - irq->irq_entry_time,
+ irq_diff, sizeof(irq_diff));
+
+ printf("
---\n");
+ printf(" Irq name | CPU | Time consume us | Handler entry
time | Handler exit time \n");
+ printf("
---\n");
+
+ ret = printf(" %s ", irq->irq_name);
+ for (i = 0; i < IRQ_NAME_LEN - ret; i++)
+ printf(" ");
+
+ printf("| [%04d] | %13s s | %16s s | %16s s\n",
+ irq->cpu, irq_diff, irq_entry_time, irq_exit_time);
+ printf("\n");
+}
+
+static int report_irq_handler_entry_event(struct perf_tool *tool,
+ union perf_event *event __maybe_unused,
+ struct evsel *evsel,
+
[PATCH v2 0/2] perf tools: add 'perf irq' to measure the hardware interrupts
When the hardware interrupt processing function is executed, the interrupt and
preemption of current cpu are disabled. As a result, the task is suspended.
The execution of the hardware processing function takes a long time
(for example 5 ms), will affect the task scheduling performance.
This patches provides the 'perf irq' command to trace and calculate the time
consumed of the hardware irq function.
[verse]
'perf irq' {record|report|script}
There are several variants of 'perf irq':
'perf irq record ' to record the irq handler events
of an arbitrary workload.
'perf irq script' to see a detailed trace of the workload that
was recorded (aliased to 'perf script' for now).
'perf irq report' to calculate the time consumed by each
hardware interrupt processing function.
Example usage:
perf irq record -- sleep 1
perf irq report
By default it shows the individual irq events, including the irq name,
cpu(execute the hardware interrupt processing function), time consumed,
entry time and exit time for the each hardware irq:
---
Irq name | CPU | Time consume us | Handler entry time | Handler
exit time
---
enp2s0f2-tx-0| [0006] | 0.01 s | 6631263.313329 s |
6631263.313330 s
---
Irq name | CPU | Time consume us | Handler entry time | Handler
exit time
---
megasas | [0013] | 0.03 s | 6631263.209564 s |
6631263.209567 s
---
Irq name | CPU | Time consume us | Handler entry time | Handler
exit time
---
acpi | [0016] | 0.18 s | 6631263.085787 s |
6631263.085805 s
And:
perf irq report --cpu 78
---
Irq name | CPU | Time consume us | Handler entry time | Handler
exit time
---
enp134s0f0-TxRx-2 | [0078] | 0.05 s |693757.533189 s |
693757.533194 s
Changes from v2:
* Delete "-m", "1024" in __cmd_record()
* Change 'perf irq timeconsume ' to 'perf irq report '
* Fix a error for tools/perf/Documentation/perf-irq.txt
Bixuan Cui (2):
perf tools: add 'perf irq' to measure the hardware interrupts
perf tools: Add documentation for 'perf irq' command
tools/perf/Build | 1 +
tools/perf/Documentation/perf-irq.txt | 58 ++
tools/perf/builtin-irq.c | 287 ++
tools/perf/builtin.h | 1 +
tools/perf/command-list.txt | 1 +
tools/perf/perf.c | 1 +
6 files changed, 349 insertions(+)
create mode 100644 tools/perf/Documentation/perf-irq.txt
create mode 100644 tools/perf/builtin-irq.c
--
2.17.1
[PATCH] drm/amdgpu: Repeat assignment to max_slave_planes
Signed-off-by: ZhiJie.Zhang --- drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c index 3f63822b8e28..9a86d43a6233 100644 --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c @@ -1272,7 +1272,6 @@ static bool underlay_create(struct dc_context *ctx, struct resource_pool *pool) /* update the public caps to indicate an underlay is available */ ctx->dc->caps.max_slave_planes = 1; - ctx->dc->caps.max_slave_planes = 1; return true; } -- 2.29.2
[PATCH net-next] net: core: use eth_type_vlan in tap_get_user_xdp
From: Menglong Dong Replace the check for ETH_P_8021Q and ETH_P_8021AD in tap_get_user_xdp with eth_type_vlan. Signed-off-by: Menglong Dong --- drivers/net/tap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/tap.c b/drivers/net/tap.c index 3c652c8ac5ba..e007583b5bd1 100644 --- a/drivers/net/tap.c +++ b/drivers/net/tap.c @@ -1164,8 +1164,7 @@ static int tap_get_user_xdp(struct tap_queue *q, struct xdp_buff *xdp) } /* Move network header to the right position for VLAN tagged packets */ - if ((skb->protocol == htons(ETH_P_8021Q) || -skb->protocol == htons(ETH_P_8021AD)) && + if (eth_type_vlan(skb->protocol) && __vlan_get_protocol(skb, skb->protocol, ) != 0) skb_set_network_header(skb, depth); -- 2.25.1
Re: [PATCH v3 3/5] perf c2c: Refactor display filter
Hi Joe,
On Wed, Jan 13, 2021 at 11:35:23PM -0800, Joe Perches wrote:
> On Thu, 2021-01-14 at 11:39 +0800, Leo Yan wrote:
> > When sort on the respective metrics (lcl_hitm, rmt_hitm, tot_hitm),
> > macro FILTER_HITM is to filter out the cache line entries if its
> > overhead is less than 1%.
> >
> > This patch introduces static function filter_display() to replace macro;
> > and refines its parameter with more flexbile way, rather than passing
> > field name, it changes to pass the cache line's statistic value and the
> > sum value.
> []
> > diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> []
> > +static u8 filter_display(u32 val, u32 sum)
> > +{
> > + double ld_dist;
> > +
> > + if (sum) {
> > + ld_dist = ((double)(val) / (sum));
> > + if (ld_dist < DISPLAY_LINE_LIMIT)
> > + return HIST_FILTER__C2C;
> > + } else {
> > + return HIST_FILTER__C2C;
> > + }
> > +
> > + return 0;
> > +}
>
> style:
>
> It's generally better to test and return early and unindent the remainder.
> Also, parentheses aren't necessary around now not-macro args.
>
> {
> if (sum == 0 || ((double)val / sum) < DISPLAY_LINE_LIMIT)
> return HIST_FILTER__C2C;
>
> return 0;
> }
Will refine for this; thanks for suggestion.
Leo
Re: [PATCH] Documentation/llvm: Add a section about supported architectures
On Thu, Jan 14, 2021 at 1:35 AM Nathan Chancellor wrote: > > The most common question around building the Linux kernel with clang is > "does it work?" and the answer has always been "it depends on your > architecture, configuration, and LLVM version" with no hard answers for > users wanting to experiment. LLVM support has significantly improved > over the past couple of years, resulting in more architectures and > configurations supported, and continuous integration has made it easier > to see what works and what does not. > > Add a section that goes over what architectures are supported in the > current kernel version, how they should be built (with just clang or the > LLVM utilities as well), and the level of support they receive. This > will make it easier for people to try out building their kernel with > LLVM and reporting issues that come about from it. > Thanks, this was overdue and is definitely helpful for users and developers. For x86 64bit: Reviewed-by: Sedat Dilek Together with "[PATCH] kbuild: check the minimum compiler version in Kconfig" this looks very good to me. /o\ - Sedat - [1] https://marc.info/?t=16105981101=1=2 > Suggested-by: Miguel Ojeda > Signed-off-by: Nathan Chancellor > --- > Documentation/kbuild/llvm.rst | 44 +++ > 1 file changed, 44 insertions(+) > > diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst > index 21c847890d03..b18401d2ba82 100644 > --- a/Documentation/kbuild/llvm.rst > +++ b/Documentation/kbuild/llvm.rst > @@ -63,6 +63,50 @@ They can be enabled individually. The full list of the > parameters: :: > Currently, the integrated assembler is disabled by default. You can pass > ``LLVM_IAS=1`` to enable it. > > +Supported Architectures > +--- > + > +LLVM does not target all of the architectures that Linux supports and > +just because a target is supported in LLVM does not mean that the kernel > +will build or work without any issues. Below is a general summary of > +architectures that currently work with ``CC=clang`` or ``LLVM=1``. Level > +of support corresponds to "S" values in the MAINTAINERS files. If an > +architecture is not present, it either means that LLVM does not target > +it or there are known issues. Using the latest stable version of LLVM or > +even the development tree will generally yield the best results. > +An architecture's ``defconfig`` is generally expected to work well, > +certain configurations may have problems that have not been uncovered > +yet. Bug reports are always welcome at the issue tracker below! > + > +.. list-table:: > + :widths: 10 10 10 > + :header-rows: 1 > + > + * - Architecture > + - Level of support > + - ``make`` command > + * - arm > + - Supported > + - ``LLVM=1`` > + * - arm64 > + - Supported > + - ``LLVM=1`` > + * - mips > + - Maintained > + - ``CC=clang`` > + * - powerpc > + - Maintained > + - ``CC=clang`` > + * - riscv > + - Maintained > + - ``CC=clang`` > + * - s390 > + - Maintained > + - ``CC=clang`` > + * - x86 > + - Supported > + - ``LLVM=1`` > + > Getting Help > > > > base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837 > -- > 2.30.0 > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clang-built-linux/20210114003447.7363-1-natechancellor%40gmail.com.
[PATCH net-next] net: tap: use eth_type_vlan in tap_get_user
From: Menglong Dong Replace the check for ETH_P_8021Q and ETH_P_8021AD in tap_get_user with eth_type_vlan. Signed-off-by: Menglong Dong --- drivers/net/tap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/tap.c b/drivers/net/tap.c index 3c652c8ac5ba..cf9197fe3bb6 100644 --- a/drivers/net/tap.c +++ b/drivers/net/tap.c @@ -713,8 +713,7 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control, skb_probe_transport_header(skb); /* Move network header to the right position for VLAN tagged packets */ - if ((skb->protocol == htons(ETH_P_8021Q) || -skb->protocol == htons(ETH_P_8021AD)) && + if (eth_type_vlan(skb->protocol) && __vlan_get_protocol(skb, skb->protocol, ) != 0) skb_set_network_header(skb, depth); -- 2.25.1
Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default
Hi Saravana,
On 13.01.2021 20:23, Saravana Kannan wrote:
> On Tue, Jan 12, 2021 at 11:04 PM Marek Szyprowski
> wrote:
>> On 12.01.2021 21:51, Saravana Kannan wrote:
>>> On Mon, Jan 11, 2021 at 11:11 PM Marek Szyprowski
>>> wrote:
On 11.01.2021 22:47, Saravana Kannan wrote:
> On Mon, Jan 11, 2021 at 6:18 AM Marek Szyprowski
> wrote:
>> On 11.01.2021 12:12, Marek Szyprowski wrote:
>>> On 18.12.2020 04:17, Saravana Kannan wrote:
Cyclic dependencies in some firmware was one of the last remaining
reasons fw_devlink=on couldn't be set by default. Now that cyclic
dependencies don't block probing, set fw_devlink=on by default.
Setting fw_devlink=on by default brings a bunch of benefits (currently,
only for systems with device tree firmware):
* Significantly cuts down deferred probes.
* Device probe is effectively attempted in graph order.
* Makes it much easier to load drivers as modules without having to
worry about functional dependencies between modules (depmod is
still
needed for symbol dependencies).
If this patch prevents some devices from probing, it's very likely due
to the system having one or more device drivers that "probe"/set up a
device (DT node with compatible property) without creating a struct
device for it. If we hit such cases, the device drivers need to be
fixed so that they populate struct devices and probe them like normal
device drivers so that the driver core is aware of the devices and
their
status. See [1] for an example of such a case.
[1] -
https://protect2.fireeye.com/v1/url?k=68f5d8ba-376ee1f5-68f453f5-0cc47a30d446-324e64700545ab93=1=fb455b9e-c8c7-40d0-8e3c-d9d3713d519b=https%3A%2F%2Flore.kernel.org%2Flkml%2FCAGETcx9PiX%3D%3DmLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw%40mail.gmail.com%2F
Signed-off-by: Saravana Kannan
>>> This patch landed recently in linux next-20210111 as commit
>>> e590474768f1 ("driver core: Set fw_devlink=on by default"). Sadly it
>>> breaks Exynos IOMMU operation, what causes lots of devices being
>>> deferred and not probed at all. I've briefly checked and noticed that
>>> exynos_sysmmu_probe() is never called after this patch. This is really
>>> strange for me, as the SYSMMU controllers on Exynos platform are
>>> regular platform devices registered by the OF code. The driver code is
>>> here: drivers/iommu/exynos-iommu.c, example dts:
>>> arch/arm/boot/dts/exynos3250.dtsi (compatible =
>>> "samsung,exynos-sysmmu").
>> Okay, I found the source of this problem. It is caused by Exynos power
>> domain driver, which is not platform driver yet. I will post a patch,
>> which converts it to the platform driver.
> Thanks Marek! Hopefully the debug logs I added were sufficient to
> figure out the reason.
Frankly, it took me a while to figure out that device core waits for the
power domain devices. Maybe it would be possible to add some more debug
messages or hints? Like the reason of the deferred probe in
/sys/kernel/debug/devices_deferred ?
>>> There's already a /sys/devices/...//waiting_for_supplier file
>>> that tells you if the device is waiting for a supplier device to be
>>> added. That file goes away once the device probes. If the file has 1,
>>> then it's waiting for the supplier device to be added (like your
>>> case). If it's 0, then the device is just waiting on one of the
>>> existing suppliers to probe. You can find the existing suppliers
>>> through /sys/devices/...//supplier:*/supplier. Also, flip
>>> these dev_dbg() to dev_info() if you need more details about deferred
>>> probing.
>> Frankly speaking I doubt that anyone will find those. Even experienced
>> developer might need some time to figure it out.
>>
>> I expect that such information will be at least in the mentioned
>> /sys/kernel/debug/devices_deferred file. We already have infrastructure
>> for putting the deferred probe reason there, see dev_err_probe()
>> function. Even such a simple change makes the debugging this issue much
>> easier:
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index cd8e518fadd6..ceb5aed5a84c 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -937,12 +937,13 @@ int device_links_check_suppliers(struct device *dev)
>> mutex_lock(_link_lock);
>> if (dev->fwnode && !list_empty(>fwnode->suppliers) &&
>> !fw_devlink_is_permissive()) {
>> - dev_dbg(dev, "probe deferral - wait for supplier %pfwP\n",
>> + ret = dev_err_probe(dev, -EPROBE_DEFER,
>> + "probe deferral - wait for supplier %pfwP\n",
>> list_first_entry(>fwnode->suppliers,
>> struct fwnode_link,
>>
[PATCH v3 1/2] checkpatch: fix false positive for COMMIT_LOG_LONG_LINE with URLs
Currently checkpatch warns for long line in commit messages even for
URL lines.
An evaluation over v5.6..v5.8 found that out of 1703 warnings reported
by this class, 161 are due to the line containg URLs. Out of these 161,
53 are due to lines where URL is the first non-whitespace character of
the line.
E.g. running checkpatch on commit 3cde818cd02b ("ASoC: topology:
Consolidate how dtexts and dvalues are freed") reports this warning:
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per
line)
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144761.html
Avoid giving users warning for character limit for such cases, instead
suggest them to prefix the URLs with "Link:"
Signed-off-by: Aditya Srivastava
---
scripts/checkpatch.pl | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e6857bdfcb2d..e8851ce73149 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3023,9 +3023,14 @@ sub process {
$line =~ /^\s*(?:Fixes:|Link:|$signature_tags)/i ||
# A Fixes: or Link: line or signature
tag line
$commit_log_possible_stack_dump)) {
- WARN("COMMIT_LOG_LONG_LINE",
-"Possible unwrapped commit description (prefer a
maximum 75 chars per line)\n" . $herecurr);
- $commit_log_long_line = 1;
+ if ($line =~ /^\s*[a-z][\w\.\+\-]*:\/\/\S+/i) {
+ WARN("COMMIT_LOG_LONG_LINE",
+"Consider prefixing the URL with
'Link:'\n" . $herecurr);
+ } else {
+ WARN("COMMIT_LOG_LONG_LINE",
+"Possible unwrapped commit description
(prefer a maximum 75 chars per line)\n" . $herecurr);
+ $commit_log_long_line = 1;
+ }
}
# Reset possible stack dump if a blank line is found
--
2.17.1
[PATCH v3 2/2] checkpatch: add fix option for COMMIT_LOG_LONG_LINE with URLs
Currently checkpatch warns for long line in commit messages even for
URL lines.
An evaluation over v5.6..v5.8 found that out of 1703 warnings reported
by this class, 161 are due to the line containg URLs. Out of these 161,
53 are due to lines where URL is the first non-whitespace character of
the line.
E.g. running checkpatch on commit 3cde818cd02b ("ASoC: topology:
Consolidate how dtexts and dvalues are freed") reports this warning:
WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per
line)
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144761.html
Provide a simple fix option by prefixing the first non-whitespace
character of the line with "Link:"
Signed-off-by: Aditya Srivastava
---
scripts/checkpatch.pl | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e8851ce73149..7030c4d6d126 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3023,9 +3023,12 @@ sub process {
$line =~ /^\s*(?:Fixes:|Link:|$signature_tags)/i ||
# A Fixes: or Link: line or signature
tag line
$commit_log_possible_stack_dump)) {
- if ($line =~ /^\s*[a-z][\w\.\+\-]*:\/\/\S+/i) {
- WARN("COMMIT_LOG_LONG_LINE",
-"Consider prefixing the URL with
'Link:'\n" . $herecurr);
+ if ($line =~ /^\s*([a-z][\w\.\+\-]*:\/\/\S+)/i) {
+ if (WARN("COMMIT_LOG_LONG_LINE",
+"Consider prefixing the URL with
'Link:'\n" . $herecurr) &&
+ $fix) {
+ $fixed[$fixlinenr] = "Link: $1";
+ }
} else {
WARN("COMMIT_LOG_LONG_LINE",
"Possible unwrapped commit description
(prefer a maximum 75 chars per line)\n" . $herecurr);
--
2.17.1
[PATCH v3 0/2] checkpatch: fix false positive for COMMIT_LOG_LONG_LINE and provide fix
Currently, checkpatch gives COMMIT_LOG_LONG_LINE warning even for URL
lines, which should be avoided.
An evaluation over v5.6..v5.8 found that out of 1703 warnings reported
by this class, 161 are due to the line containg URLs. Out of these 161,
53 are due to lines where URL is the first non-whitespace character of
the line.
Fix this false positive by suggesting to prefix the URL with "Link:".
Also provide the fix option to the user.
* Applies perfectly on next-20210108
Changes in v2:
- Fix coding style ('} else {')
- Make the URL check follow RFC 3986 style
- Give warning only if the URL is first non-whitespace of the line
- Set $commit_log_long_line only for else case
- Fix the warning count with exact figures and according to first non-space
char as URL
Changes in v3:
- Provide fix option for the warning
- Update the warning count with v5.6..v5.8
- Update regex with /^\s*[a-z][\w\.\+\-]*:\/\/\S+/i (earlier:
/^\s*\b[a-z][\w\.\+\-]*:\/\/\S+/i)
Aditya Srivastava (2):
checkpatch: fix false positive for COMMIT_LOG_LONG_LINE with URLs
checkpatch: add fix option for COMMIT_LOG_LONG_LINE with URLs
scripts/checkpatch.pl | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
--
2.17.1
Re: [PATCH v3 3/5] perf c2c: Refactor display filter
On Thu, 2021-01-14 at 11:39 +0800, Leo Yan wrote:
> When sort on the respective metrics (lcl_hitm, rmt_hitm, tot_hitm),
> macro FILTER_HITM is to filter out the cache line entries if its
> overhead is less than 1%.
>
> This patch introduces static function filter_display() to replace macro;
> and refines its parameter with more flexbile way, rather than passing
> field name, it changes to pass the cache line's statistic value and the
> sum value.
[]
> diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
[]
> +static u8 filter_display(u32 val, u32 sum)
> +{
> + double ld_dist;
> +
> + if (sum) {
> + ld_dist = ((double)(val) / (sum));
> + if (ld_dist < DISPLAY_LINE_LIMIT)
> + return HIST_FILTER__C2C;
> + } else {
> + return HIST_FILTER__C2C;
> + }
> +
> + return 0;
> +}
style:
It's generally better to test and return early and unindent the remainder.
Also, parentheses aren't necessary around now not-macro args.
{
if (sum == 0 || ((double)val / sum) < DISPLAY_LINE_LIMIT)
return HIST_FILTER__C2C;
return 0;
}
Re: [PATCH] arm64: dts: mt8183: Add missing power-domain for pwm0 node
On Thu, Jan 14, 2021 at 5:57 AM Enric Balletbo i Serra
wrote:
>
> The MT8183 display PWM device will not work until the associated
> power-domain is enabled. Add the power-domain reference to the node
> allows the display PWM driver to operate and the backlight turn on.
>
> Fixes: f15722c0fef0 ("arm64: dts: mt8183: Add pwm and backlight node")
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Hsin-Yi Wang
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index bda283fa9245..8471c973dfd5 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -661,6 +661,7 @@ pwm0: pwm@1100e000 {
> compatible = "mediatek,mt8183-disp-pwm";
> reg = <0 0x1100e000 0 0x1000>;
> interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> #pwm-cells = <2>;
> clocks = < CLK_TOP_MUX_DISP_PWM>,
> < CLK_INFRA_DISP_PWM>;
> --
> 2.29.2
>
Re: [PATCH] net: phy: micrel: reconfigure the phy on resume
On 13.01.2021 23:01, Russell King - ARM Linux admin wrote: > On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote: >> On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote: >>> On 13.01.2021 13:09, Heiner Kallweit wrote: On 13.01.2021 10:29, claudiu.bez...@microchip.com wrote: > It could enter in this mode based on request for standby or > suspend-to-mem: > echo mem > /sys/power/state > echo standby > /sys/power/state > > This is a standard way to enter S2R - I've used it many times in the > past on platforms that support it. > >> I'm not a Linux PM expert, to me it seems your use case is somewhere in the >> middle between s2r and hibernation. I *think* the assumption with s2r is >> that one component shouldn't simply cut the power to another component, >> and the kernel has no idea about it. > > When entering S2R, power can (and probably will) be cut to all system > components, certainly all components that do not support wakeup. If > the system doesn't support WoL, then that will include the ethernet > PHY. > I'm with you if we talk about a driver's suspend callback cutting power to the component it controls, or at least putting it to a power-saving state. However a driver shouldn't have to expect that during S2R somebody else cuts the power. If this would be the case, then I think we wouldn't need separate resume and restore pm callbacks in general. > When resuming, the responsibility is of the kernel and each driver's > .resume function to ensure that the hardware state is restored. Only > each device driver that knows the device itself can restore the state > of that device. In the case of an ethernet PHY, that is phylib and > its associated PHY driver. > Also in phylib we have separate functions mdio_bus_phy_resume() and mdio_bus_phy_restore(), with the first one not fully reconfiguring the PHY. > One has to be a tad careful with phylib and PHYs compared to their > MAC devices in terms of the resume order - it has not been unheard > of over the years for a MAC device to be resumed before its connected > PHY has been. > Right.
Re: [PATCH v4 2/3] Kbuild: make DWARF version a choice
On Thu, Jan 14, 2021 at 8:20 AM Sedat Dilek wrote:
>
> On Thu, Jan 14, 2021 at 12:27 AM Nick Desaulniers
> wrote:
> >
> > Sedat,
> > Thanks for testing, and congrats on https://lwn.net/Articles/839772/.
> > I always appreciate you taking the time to help test my work, and
> > other Clang+Linux kernel patches!
> >
>
> Hi Nick,
>
> cool, again in the top 15 :-).
>
> I should ask Mr. Corbet for a LWN subscription.
>
> > On Wed, Jan 13, 2021 at 1:24 PM Sedat Dilek wrote:
> > >
> > > On Wed, Jan 13, 2021 at 1:32 AM Nick Desaulniers
> > > wrote:
> > > >
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -826,12 +826,16 @@ else
> > > > DEBUG_CFLAGS += -g
> > > > endif
> > > >
> > > > -ifneq ($(LLVM_IAS),1)
> > > > -KBUILD_AFLAGS += -Wa,-gdwarf-2
> > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> > > > +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> >
> > ^ DEBUG_CFLAGS are set for everyone (all toolchains) if
> > CONFIG_DEBUG_INFO is defined.
> >
> > > > +ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
> >
> > ^ "If not using dwarf 2 and LLVM_IAS=1", ie. CONFIG_DEBUG_INFO_DWARF5
> > && CONFIG_CC_IS_GCC
> >
>
> OK, I know DWARF v2 and LLVM_IAS=1 is broken.
>
> Looks like DWARF v5 with GCC v10.2.1 and binutils v2.35.1 is currently
> (here) no good choice.
>
> > > > +# Binutils 2.35+ required for -gdwarf-4+ support.
> > > > +dwarf-aflag:= $(call
> > > > as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
> > > > +ifdef CONFIG_CC_IS_CLANG
> >
> > ^ "if clang"
> >
> > > > +DEBUG_CFLAGS += $(dwarf-aflag)
> > > > endif
> > >
> > > Why is that "ifdef CONFIG_CC_IS_CLANG"?
> >
> > That's what Arvind requested on v2, IIUC:
> > https://lore.kernel.org/lkml/x8psgmul4jmjp%2...@rani.riverdale.lan/
> >
> > > When I use GCC v10.2.1 DEBUG_CFLAGS are not set.
> >
> > You should have -gdwarf-4 (and not -Wa,-gwarf-4) set for DEBUG_CFLAGS
> > when compiling with GCC and enabling CONFIG_DEBUG_INFO_DWARF4. Can you
> > please confirm? (Perhaps you may have accidentally disabled
> > CONFIG_DEBUG_INFO by rerunning `make defconfig`?)
> >
>
> $ egrep 'CC_IS_|LD_IS|BTF|DWARF'
> config-5.11.0-rc3-5-amd64-gcc10-llvm11 | grep ^CONFIG
> CONFIG_CC_IS_GCC=y
> CONFIG_LD_IS_LLD=y
> CONFIG_DEBUG_INFO_DWARF4=y
> CONFIG_DEBUG_INFO_BTF=y
> CONFIG_DEBUG_INFO_BTF_MODULES=y
>
> $ grep '\-Wa,-gdwarf-4' build-log_5.11.0-rc3-5-amd64-gcc10-llvm11.txt
> | wc -l
> 156
I wonder why I see GNU/as here (see above CONFIG_LD_IS_LLD=y)?
$ llvm-dwarfdump-11 vmlinux | head -20 | egrep
'debug_info|format|version|DW_AT_producer'
vmlinux:file format elf64-x86-64
.debug_info contents:
0x: Compile Unit: length = 0x001e, format = DWARF32,
version = 0x0004, abbr_offset = 0x, addr_size = 0x08 (next unit at
0x0022)
DW_AT_producer("GNU AS 2.35.1")
0x0022: Compile Unit: length = 0xc1d2, format = DWARF32,
version = 0x0004, abbr_offset = 0x0012, addr_size = 0x08 (next unit at
0xc1f8)
DW_AT_producer("GNU C89 10.2.1 20210110 -mno-sse
-mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary
=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel
-mindirect-branch=thunk-extern -mindirect-branch-register
-mrecord-mcount -mfentry -march=x86-64 -g -g
dwarf-4 -O2 -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar
-fno-PIE -falign-jumps=1 -falign-loops=1
-fno-asynchronous-unwind-tables -fno-jump-tables -fno-de
lete-null-pointer-checks -fno-allow-store-data-races
-fstack-protector-strong -fno-strict-overflow -fstack-check=no
-fconserve-stack -fcf-protection=none -fno-stack-pr
otector")
Maybe, I should set all LLVM utils and linker manually, not using LLVM=1.
- Sedat -
Re: [PATCH 1/2] perf tools: add 'perf irq' to measure the hardware interrupts
On 2021/1/13 3:50, Alexei Budankov wrote:
> Hi Bixuan,
>
> On 12.01.2021 15:55, Bixuan Cui wrote:
>> Add 'perf irq' to trace/measure the hardware interrupts.
>>
>> Now three functions are provided:
>> 1. 'perf irq record ' to record the irq handler events.
>> 2. 'perf irq script' to see a detailed trace of the workload that
>>was recorded.
>> 3. 'perf irq timeconsume' to calculate the time consumed by each
>>hardware interrupt processing function.
>>
>> Signed-off-by: Bixuan Cui
> Thanks for the patches. There is still something that could be improved.
>
>> ---
>> tools/perf/Build | 1 +
>> tools/perf/builtin-irq.c | 288 +++
>> tools/perf/builtin.h | 1 +
>> tools/perf/perf.c| 1 +
>> 4 files changed, 291 insertions(+)
>> create mode 100644 tools/perf/builtin-irq.c
>>
>
>
>> +
>> +static int __cmd_record(int argc, const char **argv)
>> +{
>> +unsigned int rec_argc, i, j;
>> +const char **rec_argv;
>> +const char * const record_args[] = {
>> +"record",
>> +"-a",
> I see it works also like this:
>
> sudo perf record -p PID -c 1 -e irq:irq_handler_entry,irq:irq_handler_exit
> sudo perf record -R -c 1 -e irq:irq_handler_entry,irq:irq_handler_exit --
> find /
>
> This -a option jointly with -p option could be made configurable from
> the command line for perf irq mode.
That's true. We can add a series of commands for 'perf irq',such as record,
script and report.
So I kept the 'perf irq record'.
>
>> +"-R",
>> +"-m", "1024",
> Do you see data losses with default buffer size of 512KB
> when capturing trace in your specific use case?
>
> If not then this -m could be avoided or made configurable
> if you still need it.
Thank you for your advice, I will delete it.
general protection fault in io_uring_setup
Hello,
syzbot found the following issue on:
HEAD commit:65f0d241 Merge tag 'sound-5.11-rc4' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16bbcd98d0
kernel config: https://syzkaller.appspot.com/x/.config?x=ee2266946ed36986
dashboard link: https://syzkaller.appspot.com/bug?extid=06b7d55a62acca161485
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ef17fb50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1045ef6750
The issue was bisected to:
commit d9d05217cb6990b9a56e13b56e7a1b71e2551f6c
Author: Pavel Begunkov
Date: Fri Jan 8 20:57:25 2021 +
io_uring: stop SQPOLL submit on creator's death
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=148ba0cf50
final oops: https://syzkaller.appspot.com/x/report.txt?x=168ba0cf50
console output: https://syzkaller.appspot.com/x/log.txt?x=128ba0cf50
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+06b7d55a62acca161...@syzkaller.appspotmail.com
Fixes: d9d05217cb69 ("io_uring: stop SQPOLL submit on creator's death")
Code: e8 cc ac 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
3b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffc6a96c958 EFLAGS: 0206 ORIG_RAX: 01a9
RAX: ffda RBX: 2200 RCX: 00441889
RDX: 20ffd000 RSI: 2200 RDI: 3040
RBP: d8dd R08: 0001 R09: 20ffd000
R10: R11: 0206 R12: 20ffd000
R13: 20ffb000 R14: R15:
general protection fault, probably for non-canonical address
0xdc22: [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0110-0x0117]
CPU: 0 PID: 8444 Comm: syz-executor770 Not tainted 5.11.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:io_ring_set_wakeup_flag fs/io_uring.c:6929 [inline]
RIP: 0010:io_disable_sqo_submit fs/io_uring.c:8891 [inline]
RIP: 0010:io_uring_create fs/io_uring.c:9711 [inline]
RIP: 0010:io_uring_setup fs/io_uring.c:9739 [inline]
RIP: 0010:__do_sys_io_uring_setup fs/io_uring.c:9745 [inline]
RIP: 0010:__se_sys_io_uring_setup+0x2abb/0x37b0 fs/io_uring.c:9742
Code: c0 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 c5 31
de ff 41 be 14 01 00 00 4c 03 33 4c 89 f0 48 c1 e8 03 <42> 8a 04 28 84 c0 0f 85
46 06 00 00 41 80 0e 01 48 8b 7c 24 30 e8
RSP: 0018:c9edfca0 EFLAGS: 00010007
RAX: 0022 RBX: 888021fe50c0 RCX: 0001
RDX: dc00 RSI: 0004 RDI: c9edfb80
RBP: c9edff38 R08: dc00 R09: 0003
R10: f520001dbf71 R11: 0004 R12: 0001
R13: dc00 R14: 0114 R15: fff4
FS: 00975940() GS:8880b9c0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2204 CR3: 222d6000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441889
Code: e8 cc ac 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
3b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffc6a96c958 EFLAGS: 0206 ORIG_RAX: 01a9
RAX: ffda RBX: 2200 RCX: 00441889
RDX: 20ffd000 RSI: 2200 RDI: 3040
RBP: d8dd R08: 0001 R09: 20ffd000
R10: R11: 0206 R12: 20ffd000
R13: 20ffb000 R14: R15:
Modules linked in:
---[ end trace d873293344bf9303 ]---
RIP: 0010:io_ring_set_wakeup_flag fs/io_uring.c:6929 [inline]
RIP: 0010:io_disable_sqo_submit fs/io_uring.c:8891 [inline]
RIP: 0010:io_uring_create fs/io_uring.c:9711 [inline]
RIP: 0010:io_uring_setup fs/io_uring.c:9739 [inline]
RIP: 0010:__do_sys_io_uring_setup fs/io_uring.c:9745 [inline]
RIP: 0010:__se_sys_io_uring_setup+0x2abb/0x37b0 fs/io_uring.c:9742
Code: c0 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 c5 31
de ff 41 be 14 01 00 00 4c 03 33 4c 89 f0 48 c1 e8 03 <42> 8a 04 28 84 c0 0f 85
46 06 00 00 41 80 0e 01 48 8b 7c 24 30 e8
RSP: 0018:c9edfca0 EFLAGS: 00010007
RAX: 0022 RBX: 888021fe50c0 RCX: 0001
RDX: dc00 RSI: 0004 RDI:
Re: [PATCH V2] mlx5: vdpa: fix possible uninitialized var
On Thu, Jan 14, 2021 at 03:09:04PM +0800, Jason Wang wrote: > When compiling with -Werror=maybe-uninitialized, gcc may complains the Maybe you want to fix to: gcc may complain about possible... Other than that: Acked-by: Eli Cohen > possible uninitialized umem. Since the callers won't pass value other > than 1 to 3, making 3 as default to fix the compiler warning. > > Signed-off-by: Jason Wang > --- > drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c > b/drivers/vdpa/mlx5/net/mlx5_vnet.c > index f1d54814db97..07ccc61cd6f6 100644 > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > @@ -703,7 +703,7 @@ static void umem_destroy(struct mlx5_vdpa_net *ndev, > struct mlx5_vdpa_virtqueue > case 2: > umem = >umem2; > break; > - case 3: > + default: > umem = >umem3; > break; > } > -- > 2.25.1 >
[PATCH] rcu: better document kfree_rcu()
After changeset 5130b8fd0690 ("rcu: Introduce kfree_rcu() single-argument
macro"),
kernel-doc now emits two warnings:
./include/linux/rcupdate.h:884: warning: Excess function parameter
'ptr' description in 'kfree_rcu'
./include/linux/rcupdate.h:884: warning: Excess function parameter
'rhf' description in 'kfree_rcu'
What's happening here is that some macro magic was added in order
to call two different versions of kfree_rcu(), being the first one
with just one argument and a second one with two arguments.
That makes harder to document the kfree_rcu() arguments, which
also reflects on the documentation text.
In order to make clearer that this macro accepts optional
arguments, by using macro concatenation, changing its
definition from:
#define kfree_rcu kvfree_rcu
to:
#define kfree_rcu(ptr, rhf...) kvfree_rcu(ptr, ## rhf)
That not only helps kernel-doc to understand the macro arguemnts,
but also provides a better C definition that makes clearer that
the first argument is mandatory and the second one is optional.
Fixes: 5130b8fd0690 ("rcu: Introduce kfree_rcu() single-argument macro")
Signed-off-by: Mauro Carvalho Chehab
---
include/linux/rcupdate.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index bd04f722714f..5cc6deaa5df2 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -881,7 +881,7 @@ static inline notrace void
rcu_read_unlock_sched_notrace(void)
* The BUILD_BUG_ON check must not involve any function calls, hence the
* checks are done in macros here.
*/
-#define kfree_rcu kvfree_rcu
+#define kfree_rcu(ptr, rhf...) kvfree_rcu(ptr, ## rhf)
/**
* kvfree_rcu() - kvfree an object after a grace period.
--
2.29.2
Re: [PATCH v4 2/3] Kbuild: make DWARF version a choice
On Thu, Jan 14, 2021 at 12:27 AM Nick Desaulniers wrote: > > Sedat, > Thanks for testing, and congrats on https://lwn.net/Articles/839772/. > I always appreciate you taking the time to help test my work, and > other Clang+Linux kernel patches! > Hi Nick, cool, again in the top 15 :-). I should ask Mr. Corbet for a LWN subscription. > On Wed, Jan 13, 2021 at 1:24 PM Sedat Dilek wrote: > > > > On Wed, Jan 13, 2021 at 1:32 AM Nick Desaulniers > > wrote: > > > > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -826,12 +826,16 @@ else > > > DEBUG_CFLAGS += -g > > > endif > > > > > > -ifneq ($(LLVM_IAS),1) > > > -KBUILD_AFLAGS += -Wa,-gdwarf-2 > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2 > > > +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4 > > > +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) > > ^ DEBUG_CFLAGS are set for everyone (all toolchains) if > CONFIG_DEBUG_INFO is defined. > > > > +ifneq ($(dwarf-version-y)$(LLVM_IAS),21) > > ^ "If not using dwarf 2 and LLVM_IAS=1", ie. CONFIG_DEBUG_INFO_DWARF5 > && CONFIG_CC_IS_GCC > OK, I know DWARF v2 and LLVM_IAS=1 is broken. Looks like DWARF v5 with GCC v10.2.1 and binutils v2.35.1 is currently (here) no good choice. > > > +# Binutils 2.35+ required for -gdwarf-4+ support. > > > +dwarf-aflag:= $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y)) > > > +ifdef CONFIG_CC_IS_CLANG > > ^ "if clang" > > > > +DEBUG_CFLAGS += $(dwarf-aflag) > > > endif > > > > Why is that "ifdef CONFIG_CC_IS_CLANG"? > > That's what Arvind requested on v2, IIUC: > https://lore.kernel.org/lkml/x8psgmul4jmjp%2...@rani.riverdale.lan/ > > > When I use GCC v10.2.1 DEBUG_CFLAGS are not set. > > You should have -gdwarf-4 (and not -Wa,-gwarf-4) set for DEBUG_CFLAGS > when compiling with GCC and enabling CONFIG_DEBUG_INFO_DWARF4. Can you > please confirm? (Perhaps you may have accidentally disabled > CONFIG_DEBUG_INFO by rerunning `make defconfig`?) > $ egrep 'CC_IS_|LD_IS|BTF|DWARF' config-5.11.0-rc3-5-amd64-gcc10-llvm11 | grep ^CONFIG CONFIG_CC_IS_GCC=y CONFIG_LD_IS_LLD=y CONFIG_DEBUG_INFO_DWARF4=y CONFIG_DEBUG_INFO_BTF=y CONFIG_DEBUG_INFO_BTF_MODULES=y $ grep '\-Wa,-gdwarf-4' build-log_5.11.0-rc3-5-amd64-gcc10-llvm11.txt | wc -l 156
[PATCH 1/1] Documentation: ACPI: EINJ: Fix error type value for PCIe error
Fix the error type value for PCI Express uncorrectable non-fatal error to 0x0080 and fix the error type value for PCI Express uncorrectable fatal error to 0x0100. See Advanced Configuration and Power Interface Specification, version 6.2, table "18-409 Error Type Definition". Signed-off-by: Qiuxu Zhuo Reported-by: Lijian Zhao --- The error type values used in file drivers/acpi/apei/einj.c function available_error_type_show() are correct. Documentation/firmware-guide/acpi/apei/einj.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst index e588bccf5158..c042176e1707 100644 --- a/Documentation/firmware-guide/acpi/apei/einj.rst +++ b/Documentation/firmware-guide/acpi/apei/einj.rst @@ -50,8 +50,8 @@ The following files belong to it: 0x0010Memory Uncorrectable non-fatal 0x0020Memory Uncorrectable fatal 0x0040PCI Express Correctable - 0x0080PCI Express Uncorrectable fatal - 0x0100PCI Express Uncorrectable non-fatal + 0x0080PCI Express Uncorrectable non-fatal + 0x0100PCI Express Uncorrectable fatal 0x0200Platform Correctable 0x0400Platform Uncorrectable non-fatal 0x0800Platform Uncorrectable fatal -- 2.17.1
Re: [PATCH 0/3] arm64: cpufeature: Add filter function to control
Hi Marc, On 1/11/2021 5:40 AM, Marc Zyngier wrote: Hi Srinivas, On 2021-01-09 00:29, Srinivas Ramana wrote: This patchset adds a control function for cpufeature framework so that the feature can be controlled at runtime. Defer PAC on boot core and use the filter function added to disable PAC from command line. This will help toggling the feature on systems that do not support PAC or where PAC needs to be disabled at runtime, without modifying the core kernel. The idea of adding the filter function for cpufeature is taken from https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-25-catalin.mari...@arm.com/ https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-24-catalin.mari...@arm.com/ Srinivas Ramana (3): arm64: Defer enabling pointer authentication on boot core arm64: cpufeature: Add a filter function to cpufeature arm64: Enable control of pointer authentication using early param Documentation/admin-guide/kernel-parameters.txt | 6 +++ arch/arm64/include/asm/cpufeature.h | 8 +++- arch/arm64/include/asm/pointer_auth.h | 10 + arch/arm64/include/asm/stackprotector.h | 1 + arch/arm64/kernel/cpufeature.c | 53 +++-- arch/arm64/kernel/head.S | 4 -- 6 files changed, 64 insertions(+), 18 deletions(-) I've been working for some time on a similar series to allow a feature set to be disabled during the early boot phase, initially to prevent booting a kernel with VHE, but the mechanism is generic enough to deal with most architectural features. I took the liberty to lift your first patch and to add it to my series[1], further allowing PAuth to be disabled at boot time on top of BTI and VHE. I'd appreciate your comments on this. Thanks for sending this series. It seems to be more flexible compared you what we did. Following your discussion on allowing EXACT ftr_reg values. Btw, do you have plan to add MTE in similar lines to control the feature? We may be needing this on some systems. Thanks, M. [1] https://lore.kernel.org/r/2021032811.2455113-1-...@kernel.org Thanks, -- Srinivas R
Re: [PATCH v5 4/4] pinctrl: qcom: Don't clear pending interrupts when enabling
Quoting Douglas Anderson (2021-01-08 09:35:16)
> Let's deal with the problem like this:
> * When we mux away, we'll mask our interrupt. This isn't necessary in
> the above case since the client already masked us, but it's a good
> idea in general.
> * When we mux back will clear any interrupts and unmask.
I'm on board!
>
> Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
> Fixes: 71266d9d3936 ("pinctrl: qcom: Move clearing pending IRQ to
> .irq_request_resources callback")
> Signed-off-by: Douglas Anderson
> ---
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index a6b0c17e2f78..d5d1f3430c6c 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -51,6 +51,7 @@
> * @dual_edge_irqs: Bitmap of irqs that need sw emulated dual edge
> * detection.
> * @skip_wake_irqs: Skip IRQs that are handled by wakeup interrupt controller
> + * @disabled_for_mux: These IRQs were disabled because we muxed away.
> * @soc:Reference to soc_data of platform specific data.
> * @regs: Base addresses for the TLMM tiles.
> * @phys_base: Physical base address
> @@ -72,6 +73,7 @@ struct msm_pinctrl {
> DECLARE_BITMAP(dual_edge_irqs, MAX_NR_GPIO);
> DECLARE_BITMAP(enabled_irqs, MAX_NR_GPIO);
> DECLARE_BITMAP(skip_wake_irqs, MAX_NR_GPIO);
> + DECLARE_BITMAP(disabled_for_mux, MAX_NR_GPIO);
>
> const struct msm_pinctrl_soc_data *soc;
> void __iomem *regs[MAX_NR_TILES];
> @@ -179,6 +181,10 @@ static int msm_pinmux_set_mux(struct pinctrl_dev
> *pctldev,
> unsigned group)
> {
> struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
> + struct gpio_chip *gc = >chip;
> + unsigned int irq = irq_find_mapping(gc->irq.domain, group);
> + struct irq_data *d = irq_get_irq_data(irq);
> + unsigned int gpio_func = pctrl->soc->gpio_func;
> const struct msm_pingroup *g;
> unsigned long flags;
> u32 val, mask;
> @@ -195,6 +201,20 @@ static int msm_pinmux_set_mux(struct pinctrl_dev
> *pctldev,
> if (WARN_ON(i == g->nfuncs))
> return -EINVAL;
>
> + /*
> +* If an GPIO interrupt is setup on this pin then we need special
> +* handling. Specifically interrupt detection logic will still see
> +* the pin twiddle even when we're muxed away.
> +*
> +* When we see a pin with an interrupt setup on it then we'll disable
> +* (mask) interrupts on it when we mux away until we mux back. Note
> +* that disable_irq() refcounts and interrupts are disabled as long as
> +* at least one disable_irq() has been called.
> +*/
> + if (d && i != gpio_func &&
> + !test_and_set_bit(d->hwirq, pctrl->disabled_for_mux))
> + disable_irq(irq);
Does it need to be forced non-lazy so that it is actually disabled at
the GIC? I'm trying to understand how the lazy irq disabling plays into
this. I think it's a don't care situation because if the line twiddles
and triggers an irq then we'll actually disable it at the GIC in the
genirq core and mark it pending for resend. I wonder if we wouldn't have
to undo the pending state if we actually ignored it at the GIC
forcefully. And I also worry that it may cause a random wakeup if the
line twiddles, becomes pending at GIC and thus blocks the CPU from
running a WFI but it isn't an irq that Linux cares about because it's
muxed to UART, and then lazy handling runs and shuts it down. Is that
possible?
> +
> raw_spin_lock_irqsave(>lock, flags);
>
> val = msm_readl_ctl(pctrl, g);
> @@ -204,6 +224,20 @@ static int msm_pinmux_set_mux(struct pinctrl_dev
> *pctldev,
>
> raw_spin_unlock_irqrestore(>lock, flags);
>
> + if (d && i == gpio_func &&
> + test_and_clear_bit(d->hwirq, pctrl->disabled_for_mux)) {
> + /*
> +* Clear interrupts detected while not GPIO since we only
> +* masked things.
> +*/
> + if (d->parent_data && test_bit(d->hwirq,
> pctrl->skip_wake_irqs))
> + irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING,
> false);
So if not lazy this could go away? Although I think this is to clear out
the pending state in the GIC and not the PDC which is the parent.
> + else
> + msm_ack_intr_status(pctrl, g);
> +
> + enable_irq(irq);
> + }
> +
Re: [PATCH v6 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Wed, 13 Jan 2021, Lyude Paul wrote: > Currently, every different type of backlight hook that i915 supports is > pretty straight forward - you have a backlight, probably through PWM > (but maybe DPCD), with a single set of platform-specific hooks that are > used for controlling it. > > HDR backlights, in particular VESA and Intel's HDR backlight > implementations, can end up being more complicated. With Intel's > proprietary interface, HDR backlight controls always run through the > DPCD. When the backlight is in SDR backlight mode however, the driver > may need to bypass the TCON and control the backlight directly through > PWM. > > So, in order to support this we'll need to split our backlight callbacks > into two groups: a set of high-level backlight control callbacks in > intel_panel, and an additional set of pwm-specific backlight control > callbacks. This also implies a functional changes for how these > callbacks are used: > > * We now keep track of two separate backlight level ranges, one for the > high-level backlight, and one for the pwm backlight range > * We also keep track of backlight enablement and PWM backlight > enablement separately > * Since the currently set backlight level might not be the same as the > currently programmed PWM backlight level, we stop setting > panel->backlight.level with the currently programmed PWM backlight > level in panel->backlight.pwm_funcs->setup(). Instead, we rely > on the higher level backlight control functions to retrieve the > current PWM backlight level (in this case, intel_pwm_get_backlight()). > Note that there are still a few PWM backlight setup callbacks that > do actually need to retrieve the current PWM backlight level, although > we no longer save this value in panel->backlight.level like before. > > Additionally, we drop the call to lpt_get_backlight() in > lpt_setup_backlight(), and avoid unconditionally writing the PWM value that > we get from it and only write it back if we're in CPU mode, and switching > to PCH mode. The reason for this is because in the original codepath for > this, it was expected that the intel_panel_bl_funcs->setup() hook would be > responsible for fetching the initial backlight level. On lpt systems, the > only time we could ever be in PCH backlight mode is during the initial > driver load - meaning that outside of the setup() hook, lpt_get_backlight() > will always be the callback used for retrieving the current backlight > level. After this patch we still need to fetch and write-back the PCH > backlight value if we're switching from CPU mode to PCH, but because > intel_pwm_setup_backlight() will retrieve the backlight level after setup() > using the get() hook, which always ends up being lpt_get_backlight(). Thus > - an additional call to lpt_get_backlight() in lpt_setup_backlight() is > made redundant. > > v7: > * Use panel->backlight.pwm_funcs->get() to get the backlight level in > intel_pwm_setup_backlight(), lest we upset lockdep I think this change is wrong, as it now bypasses intel_panel_invert_pwm_level(). Please explain. I don't see anything in there that could trigger a lockdep warning. Perhaps it's the below you're referring to, but I think the root cause is different? > @@ -1788,22 +1780,17 @@ static int vlv_setup_backlight(struct intel_connector > *connector, enum pipe pipe > panel->backlight.active_low_pwm = ctl2 & BLM_POLARITY_I965; > > ctl = intel_de_read(dev_priv, VLV_BLC_PWM_CTL(pipe)); > - panel->backlight.max = ctl >> 16; > + panel->backlight.pwm_level_max = ctl >> 16; > > - if (!panel->backlight.max) > - panel->backlight.max = get_backlight_max_vbt(connector); > + if (!panel->backlight.pwm_level_max) > + panel->backlight.pwm_level_max = > get_backlight_max_vbt(connector); > > - if (!panel->backlight.max) > + if (!panel->backlight.pwm_level_max) > return -ENODEV; > > - panel->backlight.min = get_backlight_min_vbt(connector); > + panel->backlight.pwm_level_min = get_backlight_min_vbt(connector); > > - val = _vlv_get_backlight(dev_priv, pipe); Turns out this is a meaningful change, as the higher level vlv_get_backlight() function that will be called instead hits: <4>[ 12.870202] i915 :00:02.0: drm_WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex)) in intel_connector_get_pipe(connector). It's a real problem. See this, it's obvious (in retrospect): https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19348/fi-bsw-kefka/igt@run...@aborted.html https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19348/fi-bsw-kefka/boot0.txt I don't have a quick answer how this could be handled neatly. Perhaps the ->get call (or rather, intel_pwm_get_backlight) to set panel->backlight.level needs to be spread out to the end of each pwm_funcs->setup function after all? Though it's at the wrong abstraction level wrt level being a higher level, uh, level. I don't think it's
Re: [PATCH v4 4/5] mm: Fix page reference leak in soft_offline_page()
On Wed, Jan 13, 2021 at 10:18:09PM -0800, Dan Williams wrote:
> On Wed, Jan 13, 2021 at 5:50 PM HORIGUCHI NAOYA(堀口 直也)
> wrote:
> >
> > On Wed, Jan 13, 2021 at 04:43:32PM -0800, Dan Williams wrote:
> > > The conversion to move pfn_to_online_page() internal to
> > > soft_offline_page() missed that the get_user_pages() reference taken by
> > > the madvise() path needs to be dropped when pfn_to_online_page() fails.
> > > Note the direct sysfs-path to soft_offline_page() does not perform a
> > > get_user_pages() lookup.
> > >
> > > When soft_offline_page() is handed a pfn_valid() &&
> > > !pfn_to_online_page() pfn the kernel hangs at dax-device shutdown due to
> > > a leaked reference.
> > >
> > > Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn")
> > > Cc: Andrew Morton
> > > Cc: Naoya Horiguchi
> > > Cc: Michal Hocko
> > > Reviewed-by: David Hildenbrand
> > > Reviewed-by: Oscar Salvador
> > > Cc:
> > > Signed-off-by: Dan Williams
> >
> > I'm OK if we don't have any other better approach, but the proposed changes
> > make code a little messy, and I feel that get_user_pages() might be the
> > right place to fix. Is get_user_pages() expected to return struct page with
> > holding refcount for offline valid pages? I thought that such pages are
> > only used by drivers for dax-devices, but that might be wrong. Can I ask for
> > a little more explanation from this perspective?
>
> The motivation for ZONE_DEVICE is to allow get_user_pages() for "offline"
> pfns.
I missed this point, thank you.
>
> soft_offline_page() wants to only operate on "online" pfns.
Right.
>
> get_user_pages() on a dax-mapping returns an "offline" ZONE_DEVICE page.
OK.
>
> When pfn_to_online_page() fails the get_user_pages() reference needs
> to be dropped.
The background is clear to me, and I agree with this patch.
Reviewed-by: Naoya Horiguchi
>
> To be honest I dislike the entire flags based scheme for communicating
> the fact that page reference obtained by madvise needs to be dropped
> later. I'd rather pass a non-NULL 'struct page *' than redo
> pfn_to_page() conversions in the leaf functions, but that's a much
> larger change.
As Oscar mentions in another email, removing MF_COUNT_INCREASED was
recently discussed and rejected. I think that if pfn-page conversion
layer is somehow factored out from soft/hard offline handler, code would
be more readable/maintainable.
Thanks,
Naoya Horiguchi
[PATCH V2] mlx5: vdpa: fix possible uninitialized var
When compiling with -Werror=maybe-uninitialized, gcc may complains the possible uninitialized umem. Since the callers won't pass value other than 1 to 3, making 3 as default to fix the compiler warning. Signed-off-by: Jason Wang --- drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c index f1d54814db97..07ccc61cd6f6 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -703,7 +703,7 @@ static void umem_destroy(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue case 2: umem = >umem2; break; - case 3: + default: umem = >umem3; break; } -- 2.25.1
[PATCH] mm: memblock: remove return value of memblock_free_all()
No one checks the return value of memblock_free_all().
Make the return value void.
memblock_free_all() is used on mem_init() for each
architecture, and the total count of freed pages will be added
to _totalram_pages variable by calling totalram_pages_add().
so do not need to return total count of freed pages.
Signed-off-by: Daeseok Youn
---
include/linux/memblock.h | 2 +-
mm/memblock.c| 6 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 9c5cc95c7cee..076fda398dff 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -117,7 +117,7 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t
size);
int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
-unsigned long memblock_free_all(void);
+void memblock_free_all(void);
void reset_node_managed_pages(pg_data_t *pgdat);
void reset_all_zones_managed_pages(void);
void memblock_enforce_memory_reserved_overlap(void);
diff --git a/mm/memblock.c b/mm/memblock.c
index 40ca30bfa387..2a2b1fe4b659 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -2074,10 +2074,8 @@ void __init reset_all_zones_managed_pages(void)
/**
* memblock_free_all - release free pages to the buddy allocator
- *
- * Return: the number of pages actually released.
*/
-unsigned long __init memblock_free_all(void)
+void __init memblock_free_all(void)
{
unsigned long pages;
@@ -2086,8 +2084,6 @@ unsigned long __init memblock_free_all(void)
pages = free_low_memory_core_early();
totalram_pages_add(pages);
-
- return pages;
}
#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_ARCH_KEEP_MEMBLOCK)
--
2.25.1
Re: [PATCH] kbuild: check the minimum compiler version in Kconfig
On Thu, Jan 14, 2021 at 5:17 AM Masahiro Yamada wrote:
>
> Paul Gortmaker reported a regression in the GCC version check [1].
> If you use GCC 4.8, the build breaks before showing the error message
> "error Sorry, your version of GCC is too old - please use 4.9 or newer."
>
Hi Masahiro,
This patch is really helpful and user-friendly.
I ran into an issue with pahole requirement seen when
scripts/link-vmlinux.sh is run (see [1])
That happened after 3 hours of build-time.
Such things make me really unhappy.
Nathan proposed a fix for the pahole issue (see [2]).
I definitely will enjoy testing your v2.
Regards,
- Sedat -
[1] https://marc.info/?t=16103694954=1=2
[2] https://marc.info/?t=16103885153=1=2
> I do not want to apply his fix-up since it implies we would not be able
> to remove any cc-option test. Anyway, I admit checking the GCC version
> in is too late.
>
> Almost at the same time, Linus also suggested to move the compiler
> version error to Kconfig time. [2]
>
> I unified the similar two scripts, gcc-version.sh and clang-version.sh
> into the new cc-version.sh. The old scripts invoked the compiler multiple
> times (3 times for gcc-version.sh, 4 times for clang-version.sh). I
> refactored the code so the new one invokes the compiler just once, and
> also tried my best to use shell-builtin commands where possible.
>
> The new script runs faster.
>
> $ time ./scripts/clang-version.sh clang
> 12
>
> real0m0.029s
> user0m0.012s
> sys 0m0.021s
>
> $ time ./scripts/cc-version.sh clang
> Clang 12
>
> real0m0.009s
> user0m0.006s
> sys 0m0.004s
>
> The cc-version.sh also shows the error if the compiler is old:
>
> $ make defconfig CC=clang-9
> *** Default configuration is based on 'x86_64_defconfig'
> ***
> *** Compiler is too old.
> *** Your Clang version:9.0.1
> *** Minimum Clang version: 10.0.1
> ***
> scripts/Kconfig.include:46: Sorry, this compiler is unsupported.
> make[1]: *** [scripts/kconfig/Makefile:81: defconfig] Error 1
> make: *** [Makefile:602: defconfig] Error 2
>
> I removed the clang version check from
>
> For now, I did not touch in order to avoid
> merge conflict with [3], which has been queued up in the arm64 tree.
> We will be able to clean it up later.
>
> I put the stub for ICC because I see although
> I am not sure if building the kernel with ICC is well-supported.
>
> [1] https://lkml.org/lkml/2021/1/10/250
> [2] https://lkml.org/lkml/2021/1/12/1708
> [3] https://lkml.org/lkml/2021/1/12/1533
>
> Fixes: 87de84c9140e ("kbuild: remove cc-option test of -Werror=date-time")
> Reported-by: Paul Gortmaker
> Suggested-by: Linus Torvalds
> Signed-off-by: Masahiro Yamada
> ---
>
> include/linux/compiler-clang.h | 10 -
> init/Kconfig | 9 +++--
> scripts/Kconfig.include| 6 +++
> scripts/cc-version.sh | 69 ++
> scripts/clang-version.sh | 19 --
> scripts/gcc-version.sh | 20 --
> 6 files changed, 80 insertions(+), 53 deletions(-)
> create mode 100755 scripts/cc-version.sh
> delete mode 100755 scripts/clang-version.sh
> delete mode 100755 scripts/gcc-version.sh
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 98cff1b4b088..04c0a5a717f7 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -3,16 +3,6 @@
> #error "Please don't include directly, include
> instead."
> #endif
>
> -#define CLANG_VERSION (__clang_major__ * 1 \
> -+ __clang_minor__ * 100\
> -+ __clang_patchlevel__)
> -
> -#if CLANG_VERSION < 11
> -#ifndef __BPF_TRACING__
> -# error Sorry, your version of Clang is too old - please use 10.0.1 or newer.
> -#endif
> -#endif
> -
> /* Compiler specific definitions for Clang compiler */
>
> /* same as gcc, this was present in clang-2.6 so we can assume it works
> diff --git a/init/Kconfig b/init/Kconfig
> index b77c60f8b963..01108dd1318b 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -26,11 +26,11 @@ config CC_VERSION_TEXT
> and then every file will be rebuilt.
>
> config CC_IS_GCC
> - def_bool $(success,echo "$(CC_VERSION_TEXT)" | grep -q gcc)
> + def_bool $(success,test $(cc-name) = GCC)
>
> config GCC_VERSION
> int
> - default $(shell,$(srctree)/scripts/gcc-version.sh $(CC)) if CC_IS_GCC
> + default $(cc-version) if CC_IS_GCC
> default 0
>
> config LD_VERSION
> @@ -38,14 +38,15 @@ config LD_VERSION
> default $(shell,$(LD) --version | $(srctree)/scripts/ld-version.sh)
>
> config CC_IS_CLANG
> - def_bool $(success,echo "$(CC_VERSION_TEXT)" | grep -q clang)
> + def_bool $(success,test $(cc-name) = Clang)
>
> config LD_IS_LLD
> def_bool $(success,$(LD) -v | head -n 1 | grep -q LLD)
>
> config CLANG_VERSION
> int
> - default
Re: [PATCH v5 3/4] pinctrl: qcom: Properly clear "intr_ack_high" interrupts when unmasking
Quoting Douglas Anderson (2021-01-08 09:35:15)
> In commit 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for
> msm gpio") we tried to Ack interrupts during unmask. However, that
> patch forgot to check "intr_ack_high" so, presumably, it only worked
> for a certain subset of SoCs.
>
> Let's add a small accessor so we don't need to open-code the logic in
> both places.
>
> This was found by code inspection. I don't have any access to the
> hardware in question nor software that needs the Ack during unmask.
>
> Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: Stephen Boyd
One minor nit below.
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 1787ada6bfab..a6b0c17e2f78 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -96,6 +96,14 @@ MSM_ACCESSOR(intr_cfg)
> MSM_ACCESSOR(intr_status)
> MSM_ACCESSOR(intr_target)
>
> +static void msm_ack_intr_status(struct msm_pinctrl *pctrl,
> + const struct msm_pingroup *g)
> +{
> + u32 val = (g->intr_ack_high) ? BIT(g->intr_status_bit) : 0;
Would be nice to remove that extra parenthesis too.
> +
> + msm_writel_intr_status(val, pctrl, g);
> +}
> +
> static int msm_get_groups_count(struct pinctrl_dev *pctldev)
> {
> struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
> @@ -903,8 +910,7 @@ static void msm_gpio_irq_ack(struct irq_data *d)
>
> raw_spin_lock_irqsave(>lock, flags);
>
> - val = (g->intr_ack_high) ? BIT(g->intr_status_bit) : 0;
Even though it is here.
Re: [PATCH v5 2/4] pinctrl: qcom: No need to read-modify-write the interrupt status
Quoting Douglas Anderson (2021-01-08 09:35:14) > When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a > read-modify-write on the interrupt status register. On some SoCs it > makes sure that the status bit is 1 to "Ack" and on others it makes > sure that the bit is 0 to "Ack". Presumably the first type of > interrupt controller is a "write 1 to clear" type register and the > second just let you directly set the interrupt status register. > > As far as I can tell from scanning structure definitions, the > interrupt status bit is always in a register by itself. Thus with > both types of interrupt controllers it is safe to "Ack" interrupts > without doing a read-modify-write. We can do a simple write. > > It should be noted that if the interrupt status bit _was_ ever in a > register with other things (like maybe status bits for other GPIOs): > a) For "write 1 clear" type controllers then read-modify-write would >be totally wrong because we'd accidentally end up clearing >interrupts we weren't looking at. > b) For "direct set" type controllers then read-modify-write would also >be wrong because someone setting one of the other bits in the >register might accidentally clear (or set) our interrupt. > I say this simply to show that the current read-modify-write doesn't > provide any sort of "future proofing" of the code. In fact (for > "write 1 clear" controllers) the new code is slightly more "future > proof" since it would allow more than one interrupt status bits to > share a register. > > NOTE: this code fixes no bugs--it simply avoids an extra register > read. > > Signed-off-by: Douglas Anderson > --- Reviewed-by: Stephen Boyd
[PATCH v6 2/2] ASoC: cros_ec_codec: Reset I2S RX when probing
It is not guaranteed that I2S RX is disabled when the kernel booting.
For example, if the kernel crashes while it is enabled, it will keep
enabled until the next time EC reboots. Reset I2S RX when probing to
fix this issue.
Signed-off-by: Yu-Hsuan Hsu
---
Returns the error code when it fails to reset.
sound/soc/codecs/cros_ec_codec.c | 12
1 file changed, 12 insertions(+)
diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c
index f33a2a9654e7..40e437aa1d55 100644
--- a/sound/soc/codecs/cros_ec_codec.c
+++ b/sound/soc/codecs/cros_ec_codec.c
@@ -1011,6 +1011,18 @@ static int cros_ec_codec_platform_probe(struct
platform_device *pdev)
}
priv->ec_capabilities = r.capabilities;
+ /* Reset EC codec i2s rx. */
+ p.cmd = EC_CODEC_I2S_RX_RESET;
+ ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX,
+ (uint8_t *), sizeof(p), NULL, 0);
+ if (ret == -ENOPROTOOPT) {
+ dev_info(dev,
+"Command not found. Please update the EC firmware.\n");
+ } else if (ret) {
+ dev_err(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret);
+ return ret;
+ }
+
platform_set_drvdata(pdev, priv);
ret = devm_snd_soc_register_component(dev, _rx_component_driver,
--
2.30.0.284.gd98b1dd5eaa7-goog
[PATCH v6 1/2] cros_ec_commands: Add EC_CODEC_I2S_RX_RESET
Add the new command EC_CODEC_I2S_RX_RESET in ec_codec_i2s_rx_subcmd,
which is used for resetting the EC codec.
Signed-off-by: Yu-Hsuan Hsu
---
include/linux/platform_data/cros_ec_commands.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/cros_ec_commands.h
b/include/linux/platform_data/cros_ec_commands.h
index 86376779ab31..95889ada83a3 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -4600,6 +4600,7 @@ enum ec_codec_i2s_rx_subcmd {
EC_CODEC_I2S_RX_SET_SAMPLE_DEPTH = 0x2,
EC_CODEC_I2S_RX_SET_DAIFMT = 0x3,
EC_CODEC_I2S_RX_SET_BCLK = 0x4,
+ EC_CODEC_I2S_RX_RESET = 0x5,
EC_CODEC_I2S_RX_SUBCMD_COUNT,
};
--
2.30.0.284.gd98b1dd5eaa7-goog
Re: [PATCH] tools/bootconfig: Add tracing_on support to helper scripts
On Wed, 13 Jan 2021 18:11:58 -0500
Steven Rostedt wrote:
>
> Just noticed this patch. I'm adding it into my queue for the next merge
> window, as it doesn't look too urgent.
Yes, it is not urgent, but it might be better to backport to 5.10.
Thank you,
>
> -- Steve
>
>
> On Wed, 9 Dec 2020 14:27:44 +0900
> Masami Hiramatsu wrote:
>
> > Add ftrace.instance.INSTANCE.tracing_on support to ftrace2bconf.sh
> > and bconf2ftrace.sh.
> >
> > commit 8490db06f914 ("tracing/boot: Add per-instance tracing_on
> > option support") added the per-instance tracing_on option,
> > but forgot to update the helper scripts.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > tools/bootconfig/scripts/bconf2ftrace.sh |1 +
> > tools/bootconfig/scripts/ftrace2bconf.sh |4
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/tools/bootconfig/scripts/bconf2ftrace.sh
> > b/tools/bootconfig/scripts/bconf2ftrace.sh
> > index 595e164dc352..feb30c2c7881 100755
> > --- a/tools/bootconfig/scripts/bconf2ftrace.sh
> > +++ b/tools/bootconfig/scripts/bconf2ftrace.sh
> > @@ -152,6 +152,7 @@ setup_instance() { # [instance]
> > set_array_of ${instance}.options ${instancedir}/trace_options
> > set_value_of ${instance}.trace_clock ${instancedir}/trace_clock
> > set_value_of ${instance}.cpumask ${instancedir}/tracing_cpumask
> > + set_value_of ${instance}.tracing_on ${instancedir}/tracing_on
> > set_value_of ${instance}.tracer ${instancedir}/current_tracer
> > set_array_of ${instance}.ftrace.filters \
> > ${instancedir}/set_ftrace_filter
> > diff --git a/tools/bootconfig/scripts/ftrace2bconf.sh
> > b/tools/bootconfig/scripts/ftrace2bconf.sh
> > index 6c0d4b61e0c2..a0c3bcc6da4f 100755
> > --- a/tools/bootconfig/scripts/ftrace2bconf.sh
> > +++ b/tools/bootconfig/scripts/ftrace2bconf.sh
> > @@ -221,6 +221,10 @@ instance_options() { # [instance-name]
> > if [ `echo $val | sed -e s/f//g`x != x ]; then
> > emit_kv $PREFIX.cpumask = $val
> > fi
> > + val=`cat $INSTANCE/tracing_on`
> > + if [ `echo $val | sed -e s/f//g`x != x ]; then
> > + emit_kv $PREFIX.tracing_on = $val
> > + fi
> >
> > val=
> > for i in `cat $INSTANCE/set_event`; do
>
--
Masami Hiramatsu
Re: [PATCH] drivers: crypto: marvell: Fix a spelling s/fautly/faultly/ in comment
On Tue, Jan 05, 2021 at 03:31:08PM +0530, Bhaskar Chowdhury wrote: > > s/fautly/faulty/p > > > Signed-off-by: Bhaskar Chowdhury > --- > drivers/crypto/marvell/cesa/tdma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: hisilicon/qm - SVA bugfixed on Kunpeng920
On Tue, Jan 05, 2021 at 02:12:03PM +0800, Kai Ye wrote: > Kunpeng920 SEC/HPRE/ZIP cannot support running user space SVA and kernel > Crypto at the same time. Therefore, the algorithms should not be registered > to Crypto as user space SVA is enabled. > > Signed-off-by: Kai Ye > Reviewed-by: Zaibo Xu > Reviewed-by: Zhou Wang > --- > drivers/crypto/hisilicon/qm.c | 6 ++ > 1 file changed, 6 insertions(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: hisilicon - register device to uacce
On Tue, Jan 05, 2021 at 02:16:41PM +0800, Kai Ye wrote: > 1. Add parameter of UACCE mode selection for ZIP. > 2. Register SEC and HPRE devices to UACCE framework for user space drivers. > > Kai Ye (3): > crypto: hisilicon - add ZIP device using mode parameter > crypto: hisilicon/hpre - register HPRE device to uacce > crypto: hisilicon/sec - register SEC device to uacce > > drivers/crypto/hisilicon/hpre/hpre_main.c | 54 > +++ > drivers/crypto/hisilicon/qm.c | 2 +- > drivers/crypto/hisilicon/qm.h | 27 > drivers/crypto/hisilicon/sec2/sec_main.c | 39 +- > drivers/crypto/hisilicon/zip/zip_main.c | 14 > 5 files changed, 134 insertions(+), 2 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] udf: fix the problem that the disc content is not displayed
On 2021-01-13 20:51, 常廉志 wrote: >> On 2021-01-11 23:53, lianzhi chang wrote: >> When the capacity of the disc is too large (assuming the 4.7G specification), the disc (UDF file system) will be burned multiple times in the windows (Multisession Usage). When the remaining capacity of the CD is less than 300M (estimated value, for reference only), open the CD in the Linux system, the content of the CD is displayed as blank (the kernel will say "No VRS found"). Windows can display the contents of the CD normally. Through analysis, in the "fs/udf/super.c": udf_check_vsd function, the actual value of VSD_MAX_SECTOR_OFFSET may be much larger than 0x80. According to the current code >>> l>ogic, it is found that the type of sbi->s_session is "__s32", when the remaining capacity of the disc is less than 300M (take a set of test values: sector=3154903040, sbi->s_session=1540464, sb->s_blocksize_bits=11 ), the calculation result of "sbi->s_session << sb->s_blocksize_bits" will overflow. Therefore, it is necessary to convert the type of s_session to "loff_t" (when udf_check_vsd starts, assign a value to _sector, which is also converted in this way), so that the result will not overflow, and then the content of the disc can be displayed normally. >>> Signed-off-by: lianzhi chang --- fs/udf/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/udf/super.c b/fs/udf/super.c index 5bef3a68395d..6c3069cd1321 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -757,7 +757,7 @@ static int udf_check_vsd(struct super_block *sb) if (nsr > 0) return 1; - else if (!bh && sector - (sbi->s_session << sb->s_blocksize_bits) == + else if (!bh && sector - ((loff_t)sbi->s_session << sb->s_blocksize_bits) == VSD_FIRST_SECTOR_OFFSET) return -1; else >>> >>> >>> Looks good. Perhaps consider factoring out the conversion (which also >>> occurs >>> earlier in the function) so that the complexity of this "else if" can >>> be >>> reduced? >>> >> >>> Reviewed-by: Steven J. Magnani >> >> Thank you very much! So, which one of the following methods do you >> think is better: >> >> (1) Change the type of s_session in struct udf_sb_info to __s64. If you >> modify this way, it may involve some memory copy problems of the >> structure, and there are more modifications. >> >> (2) Definition: loff_t sector_offset=sbi->s_session << >> sb->s_blocksize_bits, and then put sector_offset into the "else if" >> statement. >> >> (3) Or is there any other better way? >I had #2 in mind. > > Steven J. Magnani "I claim this network for MARS! Thank you very much for your suggestion, I will submit a new patch
Re: [PATCH v4 4/5] mm: Fix page reference leak in soft_offline_page()
On 2021-01-14 07:18, Dan Williams wrote: To be honest I dislike the entire flags based scheme for communicating the fact that page reference obtained by madvise needs to be dropped later. I'd rather pass a non-NULL 'struct page *' than redo pfn_to_page() conversions in the leaf functions, but that's a much larger change. We tried to remove that flag in the past but for different reasons. I will have another look to see what can be done. Thanks -- Oscar Salvador SUSE L3
[PATCH 1/3] dt-bindings: usb: update snps,dwc3.yaml references
Changeset 389d77658801 ("dt-bindings: usb: Convert DWC USB3 bindings to DT
schema")
renamed: Documentation/devicetree/bindings/usb/dwc3.txt
to: Documentation/devicetree/bindings/usb/snps,dwc3.yaml.
Update its cross-references accordingly.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/devicetree/bindings/usb/dwc3-st.txt| 2 +-
Documentation/devicetree/bindings/usb/exynos-usb.txt | 2 +-
Documentation/devicetree/bindings/usb/omap-usb.txt | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index df0e02e1ee43..ad526e76f2a8 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -31,7 +31,7 @@ See:
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
Sub-nodes:
The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
example below. The DT binding details of dwc3 can be found in:
-Documentation/devicetree/bindings/usb/dwc3.txt
+Documentation/devicetree/bindings/usb/snps,dwc3.yaml
NB: The dr_mode property described in [1] is NOT optional for this driver, as
the default value
is "otg", which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either "host"
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 6aae1544f240..f7ae79825d7d 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -93,7 +93,7 @@ Sub-nodes:
The dwc3 core should be added as subnode to Exynos dwc3 glue.
- dwc3 :
The binding details of dwc3 can be found in:
- Documentation/devicetree/bindings/usb/dwc3.txt
+ Documentation/devicetree/bindings/usb/snps,dwc3.yaml
Example:
usb@1200 {
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8507cf..f0dbc5ae45ae 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -65,7 +65,7 @@ Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
The binding details of dwc3 can be found in:
- Documentation/devicetree/bindings/usb/dwc3.txt
+ Documentation/devicetree/bindings/usb/snps,dwc3.yaml
omap_dwc3 {
compatible = "ti,dwc3";
--
2.29.2
[PATCH 0/3] Fix broken references at next-20210114 due to yaml conversion
Three new broken references were added between next-20210113 and next-20210114, due to yaml conversion. Address them. Please add those patches at the same tree as the respective conversion changesets were added. Thanks! Mauro Mauro Carvalho Chehab (3): dt-bindings: usb: update snps,dwc3.yaml references Documentation/devicetree/bindings/usb/dwc3-st.txt: update usb-drd.yaml reference MAINTAINERS: update mediatek,ufs-phy.yaml reference Documentation/devicetree/bindings/usb/dwc3-st.txt| 4 ++-- Documentation/devicetree/bindings/usb/exynos-usb.txt | 2 +- Documentation/devicetree/bindings/usb/omap-usb.txt | 2 +- MAINTAINERS | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) -- 2.29.2
[PATCH 3/3] MAINTAINERS: update mediatek,ufs-phy.yaml reference
Changeset 67038ec1bdfb ("dt-bindings: phy: convert phy-mtk-ufs.txt to YAML
schema")
renamed: Documentation/devicetree/bindings/phy/phy-mtk-*
to: Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml.
Update its cross-reference accordingly.
Signed-off-by: Mauro Carvalho Chehab
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b15037d9b01d..6cf24e7fc569 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,7 +2093,7 @@ M:Chunfeng Yun
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L: linux-media...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: Documentation/devicetree/bindings/phy/phy-mtk-*
+F: Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml*
F: drivers/phy/mediatek/
ARM/Microchip (AT91) SoC support
--
2.29.2
[PATCH 2/3] Documentation/devicetree/bindings/usb/dwc3-st.txt: update usb-drd.yaml reference
Changeset b0864e1a4d9d ("dt-bindings: usb: Convert generic USB properties to DT
schemas")
renamed: Documentation/devicetree/bindings/usb/generic.txt
to: Documentation/devicetree/bindings/usb/usb-drd.yaml.
Update its cross-reference accordingly.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
index ad526e76f2a8..bf73de0d5b4a 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-st.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -37,7 +37,7 @@ NB: The dr_mode property described in [1] is NOT optional for
this driver, as th
is "otg", which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either "host"
or "device".
-[1] Documentation/devicetree/bindings/usb/generic.txt
+[1] Documentation/devicetree/bindings/usb/usb-drd.yaml
Example:
--
2.29.2
hppa64-linux-ld: kernel/trace/ftrace.o(.text+0x3d4c): cannot reach ftrace_bug
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO and AutoFDO input sections date: 5 months ago config: parisc-randconfig-r006-20210114 (attached as .config) compiler: hppa64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xc788): cannot reach strcmp hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xc8d8): cannot reach strim hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xc974): cannot reach strcmp hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xca10): cannot reach strsep hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xcdb4): cannot reach strim hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xce54): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xce88): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd060): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd094): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd1d4): cannot reach strim hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd1f0): cannot reach strcmp hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd4a8): cannot reach _raw_spin_lock_bh hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd4c0): cannot reach idr_remove hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xd4d4): cannot reach _raw_spin_unlock_bh hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xda3c): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xda70): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xdb38): cannot reach idr_remove hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xdb50): cannot reach mutex_unlock hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xdd1c): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xdd48): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xddec): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xde08): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xdf24): cannot reach strchr hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe03c): cannot reach _raw_spin_lock_irqsave hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe168): cannot reach _raw_spin_unlock_irqrestore hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe32c): cannot reach _raw_spin_lock_irqsave hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe460): cannot reach _raw_spin_unlock_irqrestore hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe530): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe594): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe6bc): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe7c8): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe8b4): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe8fc): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe938): cannot reach _raw_spin_lock_irqsave hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xe968): cannot reach _raw_spin_unlock_irqrestore hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xef10): cannot reach mutex_lock hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xef2c): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xf174): cannot reach _raw_spin_unlock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xf190): cannot reach mutex_unlock hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xf3d0): cannot reach _raw_spin_lock_irq hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xf4c8): cannot reach _raw_spin_lock_irqsave hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xf4fc): cannot reach _raw_spin_unlock_irqrestore hppa64-linux-ld: kernel/cgroup/cgroup.o(.text+0xf5a0): cannot reach _raw_spin_lock hppa64-linux-ld:
Re: [PATCH] mmc: sdhci-pci-gli: Enlarge ASPM L1 entry delay of GL9763E
> Ulf Hansson 於 2021年1月13日 週三 下午6:53寫道： > > On Wed, 6 Jan 2021 at 10:27, Renius Chen wrote: > > > > The R/W performance of GL9763E is low with some platforms, which > > support ASPM mechanism, due to entering L1 state very frequently > > in R/W process. Enlarge its ASPM L1 entry delay to improve the > > R/W performance of GL9763E. > > What do you mean by frequently? In between a burst of request or > during a burst of request? GL9763E enters ASPM L1 state after a very short idle in default, even during a burst of request. > I am thinking that this could have an effect on energy instead, but I > guess it's not always straightforward to decide what's most important. > > Anyway, what does it mean when you change to use 0x3FF? Are you > increasing the idle period? Then for how long? Yes, we considered that having high performance is more important than saving power during a burst of request. So we increased the idle period for 260us, by setting 0x3FF to the ASPM L1 entry delay bits of our vendor-specific register. Anyway, GL9763E can still enter ASPM L1 state by a longer idle. Thanks for reviewing. Best regards, Renius > Kind regards > Uffe > > > > > Signed-off-by: Renius Chen > > --- > > drivers/mmc/host/sdhci-pci-gli.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/mmc/host/sdhci-pci-gli.c > > b/drivers/mmc/host/sdhci-pci-gli.c > > index c6a107d7c742..2d13bfcbcacf 100644 > > --- a/drivers/mmc/host/sdhci-pci-gli.c > > +++ b/drivers/mmc/host/sdhci-pci-gli.c > > @@ -88,6 +88,10 @@ > > #define PCIE_GLI_9763E_SCR 0x8E0 > > #define GLI_9763E_SCR_AXI_REQ BIT(9) > > > > +#define PCIE_GLI_9763E_CFG2 0x8A4 > > +#define GLI_9763E_CFG2_L1DLYGENMASK(28, 19) > > +#define GLI_9763E_CFG2_L1DLY_MAX 0x3FF > > + > > #define PCIE_GLI_9763E_MMC_CTRL 0x960 > > #define GLI_9763E_HS400_SLOW BIT(3) > > > > @@ -792,6 +796,11 @@ static void gli_set_gl9763e(struct sdhci_pci_slot > > *slot) > > value &= ~GLI_9763E_HS400_SLOW; > > pci_write_config_dword(pdev, PCIE_GLI_9763E_MMC_CTRL, value); > > > > + pci_read_config_dword(pdev, PCIE_GLI_9763E_CFG2, ); > > + value &= ~GLI_9763E_CFG2_L1DLY; > > + value |= FIELD_PREP(GLI_9763E_CFG2_L1DLY, GLI_9763E_CFG2_L1DLY_MAX); > > + pci_write_config_dword(pdev, PCIE_GLI_9763E_CFG2, value); > > + > > pci_read_config_dword(pdev, PCIE_GLI_9763E_VHS, ); > > value &= ~GLI_9763E_VHS_REV; > > value |= FIELD_PREP(GLI_9763E_VHS_REV, GLI_9763E_VHS_REV_R); > > -- > > 2.27.0 > >
[PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
A typical USB keyboard usually splits its keys into several reports:
- one for the basic alphanumeric keys, modifier keys, F keys, six pack
keys and keypad. This report's application is normally listed as
GenericDesktop.Keyboard
- a GenericDesktop.SystemControl report for the system control keys, such
as power and sleep
- Consumer.ConsumerControl report for multimedia (forward, rewind,
play/pause, mute, etc) and other extended keys.
- additional output, vendor specific, and feature reports
Splitting each report into a separate input device is wasteful and even
hurts userspace as it makes it harder to determine the true capabilities
(set of available keys) of a keyboard, so let's adjust application
matching to merge system control and consumer control reports with
keyboard report, if one has already been processed.
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-input.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index f797659cb9d9..df45d8d07dc2 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1851,6 +1851,16 @@ static struct hid_input
*hidinput_match_application(struct hid_report *report)
list_for_each_entry(hidinput, >inputs, list) {
if (hidinput->application == report->application)
return hidinput;
+
+ /*
+* Keep SystemControl and ConsumerControl applications together
+* with the main keyboard, if present.
+*/
+ if ((report->application == HID_GD_SYSTEM_CONTROL ||
+report->application == HID_CP_CONSUMER_CONTROL) &&
+ hidinput->application == HID_GD_KEYBOARD) {
+ return hidinput;
+ }
}
return NULL;
--
2.30.0.284.gd98b1dd5eaa7-goog
--
Dmitry
[PATCH v2 2/2] f2fs: add ckpt_thread_ioprio sysfs node
From: Daeho Jeong
Added "ckpt_thread_ioprio" sysfs node to give a way to change checkpoint
merge daemon's io priority. Its default value is "be,3", which means
"BE" I/O class and I/O priority "3". We can select the class between "rt"
and "be", and set the I/O priority within valid range of it.
"," delimiter is necessary in between I/O class and priority number.
Signed-off-by: Daeho Jeong
---
v2:
- adapt to inlining ckpt_req_control of f2fs_sb_info
---
Documentation/ABI/testing/sysfs-fs-f2fs | 8
fs/f2fs/checkpoint.c| 2 +-
fs/f2fs/f2fs.h | 1 +
fs/f2fs/sysfs.c | 51 +
4 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 3dfee94e0618..0c48b2e7dfd4 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -377,3 +377,11 @@ Description: This gives a control to limit the bio
size in f2fs.
Default is zero, which will follow underlying block layer limit,
whereas, if it has a certain bytes value, f2fs won't submit a
bio larger than that size.
+What: /sys/fs/f2fs//ckpt_thread_ioprio
+Date: January 2021
+Contact: "Daeho Jeong"
+Description: Give a way to change checkpoint merge daemon's io priority.
+ Its default value is "be,3", which means "BE" I/O class and
+ I/O priority "3". We can select the class between "rt" and "be",
+ and set the I/O priority within valid range of it. "," delimiter
+ is necessary in between I/O class and priority number.
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index e0668cec3b80..62bd6f449bb7 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1840,7 +1840,7 @@ int f2fs_start_ckpt_thread(struct f2fs_sb_info *sbi)
if (IS_ERR(cprc->f2fs_issue_ckpt))
return PTR_ERR(cprc->f2fs_issue_ckpt);
- set_task_ioprio(cprc->f2fs_issue_ckpt, DEFAULT_CHECKPOINT_IOPRIO);
+ set_task_ioprio(cprc->f2fs_issue_ckpt, cprc->ckpt_thread_ioprio);
return 0;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index f2ae075aa723..517eb0eda638 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -276,6 +276,7 @@ struct ckpt_req {
struct ckpt_req_control {
struct task_struct *f2fs_issue_ckpt;/* checkpoint task */
+ int ckpt_thread_ioprio; /* checkpoint merge thread
ioprio */
wait_queue_head_t ckpt_wait_queue; /* waiting queue for wake-up */
atomic_t issued_ckpt; /* # of actually issued ckpts */
atomic_t total_ckpt;/* # of total ckpts */
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 30bae57428d1..ddd70395148d 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "segment.h"
@@ -34,6 +35,7 @@ enum {
FAULT_INFO_TYPE,/* struct f2fs_fault_info */
#endif
RESERVED_BLOCKS,/* struct f2fs_sb_info */
+ CPRC_INFO, /* struct ckpt_req_control */
};
struct f2fs_attr {
@@ -70,6 +72,8 @@ static unsigned char *__struct_ptr(struct f2fs_sb_info *sbi,
int struct_type)
else if (struct_type == STAT_INFO)
return (unsigned char *)F2FS_STAT(sbi);
#endif
+ else if (struct_type == CPRC_INFO)
+ return (unsigned char *)>cprc_info;
return NULL;
}
@@ -255,6 +259,23 @@ static ssize_t f2fs_sbi_show(struct f2fs_attr *a,
return len;
}
+ if (!strcmp(a->attr.name, "ckpt_thread_ioprio")) {
+ struct ckpt_req_control *cprc = >cprc_info;
+ int len = 0;
+ int class = IOPRIO_PRIO_CLASS(cprc->ckpt_thread_ioprio);
+ int data = IOPRIO_PRIO_DATA(cprc->ckpt_thread_ioprio);
+
+ if (class == IOPRIO_CLASS_RT)
+ len += scnprintf(buf + len, PAGE_SIZE - len, "rt,");
+ else if (class == IOPRIO_CLASS_BE)
+ len += scnprintf(buf + len, PAGE_SIZE - len, "be,");
+ else
+ return -EINVAL;
+
+ len += scnprintf(buf + len, PAGE_SIZE - len, "%d\n", data);
+ return len;
+ }
+
ui = (unsigned int *)(ptr + a->offset);
return sprintf(buf, "%u\n", *ui);
@@ -308,6 +329,34 @@ static ssize_t __sbi_store(struct f2fs_attr *a,
return ret ? ret : count;
}
+ if (!strcmp(a->attr.name, "ckpt_thread_ioprio")) {
+ const char *name = strim((char *)buf);
+ struct ckpt_req_control *cprc = >cprc_info;
+ int class;
+ long data;
+ int ret;
+
+ if (!strncmp(name, "rt,", 3))
+ class =
[PATCH v2 1/2] f2fs: introduce checkpoint=merge mount option
From: Daeho Jeong
We've added a new mount option "checkpoint=merge", which creates a
kernel daemon and makes it to merge concurrent checkpoint requests as
much as possible to eliminate redundant checkpoint issues. Plus, we
can eliminate the sluggish issue caused by slow checkpoint operation
when the checkpoint is done in a process context in a cgroup having
low i/o budget and cpu shares, and The below verification result
explains this.
The basic idea has come from https://opensource.samsung.com.
[Verification]
Android Pixel Device(ARM64, 7GB RAM, 256GB UFS)
Create two I/O cgroups (fg w/ weight 100, bg w/ wight 20)
Set "strict_guarantees" to "1" in BFQ tunables
In "fg" cgroup,
- thread A => trigger 1000 checkpoint operations
"for i in `seq 1 1000`; do touch test_dir1/file; fsync test_dir1;
done"
- thread B => gererating async. I/O
"fio --rw=write --numjobs=1 --bs=128k --runtime=3600 --time_based=1
--filename=test_img --name=test"
In "bg" cgroup,
- thread C => trigger repeated checkpoint operations
"echo $$ > /dev/blkio/bg/tasks; while true; do touch test_dir2/file;
fsync test_dir2; done"
We've measured thread A's execution time.
[ w/o patch ]
Elapsed Time: Avg. 68 seconds
[ w/ patch ]
Elapsed Time: Avg. 48 seconds
Signed-off-by: Daeho Jeong
Signed-off-by: Sungjong Seo
---
v2:
- inlined ckpt_req_control into f2fs_sb_info and collected stastics
of checkpoint merge operations
---
Documentation/filesystems/f2fs.rst | 6 ++
fs/f2fs/checkpoint.c | 163 +
fs/f2fs/debug.c| 12 +++
fs/f2fs/f2fs.h | 27 +
fs/f2fs/super.c| 56 +-
5 files changed, 260 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index dae15c96e659..bccc021bf31a 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -247,6 +247,12 @@ checkpoint=%s[:%u[%]] Set to "disable" to turn off
checkpointing. Set to "enabl
hide up to all remaining free space. The actual space
that
would be unusable can be viewed at
/sys/fs/f2fs//unusable
This space is reclaimed once checkpoint=enable.
+Here is another option "merge", which creates a kernel
daemon
+and makes it to merge concurrent checkpoint requests
as much
+as possible to eliminate redundant checkpoint issues.
Plus,
+we can eliminate the sluggish issue caused by slow
checkpoint
+operation when the checkpoint is done in a process
context in
+a cgroup having low i/o budget and cpu shares.
compress_algorithm=%s Control compress algorithm, currently f2fs supports
"lzo",
"lz4", "zstd" and "lzo-rle" algorithm.
compress_log_size=%uSupport configuring compress cluster size, the size
will
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 897edb7c951a..e0668cec3b80 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "node.h"
@@ -20,6 +21,8 @@
#include "trace.h"
#include
+#define DEFAULT_CHECKPOINT_IOPRIO (IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, 3))
+
static struct kmem_cache *ino_entry_slab;
struct kmem_cache *f2fs_inode_entry_slab;
@@ -1707,3 +1710,163 @@ void f2fs_destroy_checkpoint_caches(void)
kmem_cache_destroy(ino_entry_slab);
kmem_cache_destroy(f2fs_inode_entry_slab);
}
+
+static int __write_checkpoint_sync(struct f2fs_sb_info *sbi)
+{
+ struct cp_control cpc = { .reason = CP_SYNC, };
+ int err;
+
+ down_write(>gc_lock);
+ err = f2fs_write_checkpoint(sbi, );
+ up_write(>gc_lock);
+
+ return err;
+}
+
+static void __checkpoint_and_complete_reqs(struct f2fs_sb_info *sbi)
+{
+ struct ckpt_req_control *cprc = >cprc_info;
+ struct ckpt_req *req, *next;
+ struct llist_node *dispatch_list;
+ u64 sum_diff = 0, diff, count = 0;
+ int ret;
+
+ dispatch_list = llist_del_all(>issue_list);
+ if (!dispatch_list)
+ return;
+ dispatch_list = llist_reverse_order(dispatch_list);
+
+ ret = __write_checkpoint_sync(sbi);
+ atomic_inc(>issued_ckpt);
+
+ llist_for_each_entry_safe(req, next, dispatch_list, llnode) {
+ atomic_dec(>queued_ckpt);
+ atomic_inc(>total_ckpt);
+ diff = (u64)ktime_ms_delta(ktime_get(), req->queue_time);
+ req->ret = ret;
+ complete(>wait);
+
+ sum_diff += diff;
+ count++;
+ }
+
+ spin_lock(>stat_lock);
+ cprc->cur_time = (unsigned int)div64_u64(sum_diff, count);
+ if (cprc->peak_time < cprc->cur_time)
+
Re: [PATCH RESEND v2] drm/bridge/tc358775: Fixes bus formats read
Hi Vinay,
Thank you for the patch.
I'm afraid I've had close to no time for DRM bridge maintenance over the
past few months, and I don't expect the situation to improve soon. I
know how painful it can be to keep pinging without receiving any reply.
I'm sorry about that, we have a shortage of maintainers for this part of
the subsystem and it seems difficult to recruit.
On Thu, Oct 22, 2020 at 12:15:47PM +0530, Vinay Simha BN wrote:
> - atomic_check removed
> - video data input and output formats added
> - bus formats read from drm_bridge_state.output_bus_cfg.format
> and .atomic_get_input_bus_fmts() instead of connector
>
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
> * Laurent Pinchart review comments incorporated
>drm_bridge_state.output_bus_cfg.format
>instead of connector
> v2:
> * Laurent Pinchart review comments incorporated
>atomic_check removed
>video data input and output formats added
> ---
> drivers/gpu/drm/bridge/tc358775.c | 75
> ++-
> 1 file changed, 58 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> index 2272adc..cc27570 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -271,6 +271,20 @@ struct tc_data {
> struct gpio_desc*stby_gpio;
> u8 lvds_link; /* single-link or dual-link */
> u8 bpc;
> + u32 output_bus_fmt;
> +};
> +
> +static const u32 tc_lvds_in_bus_fmts[] = {
> + MEDIA_BUS_FMT_RGB565_1X16,
> + MEDIA_BUS_FMT_RGB666_1X18,
> + MEDIA_BUS_FMT_RGB666_1X24_CPADHI,
> + MEDIA_BUS_FMT_RBG888_1X24,
> +};
> +
> +static const u32 tc_lvds_out_bus_fmts[] = {
> + MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
> + MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> };
>
> static inline struct tc_data *bridge_to_tc(struct drm_bridge *b)
> @@ -359,19 +373,6 @@ static void d2l_write(struct i2c_client *i2c, u16 addr,
> u32 val)
> ret, addr);
> }
>
> -/* helper function to access bus_formats */
> -static struct drm_connector *get_connector(struct drm_encoder *encoder)
> -{
> - struct drm_device *dev = encoder->dev;
> - struct drm_connector *connector;
> -
> - list_for_each_entry(connector, >mode_config.connector_list, head)
> - if (connector->encoder == encoder)
> - return connector;
> -
> - return NULL;
> -}
> -
> static void tc_bridge_enable(struct drm_bridge *bridge)
> {
> struct tc_data *tc = bridge_to_tc(bridge);
> @@ -380,7 +381,10 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> u32 val = 0;
> u16 dsiclk, clkdiv, byteclk, t1, t2, t3, vsdelay;
> struct drm_display_mode *mode;
> - struct drm_connector *connector = get_connector(bridge->encoder);
> + struct drm_bridge_state *state =
> + drm_priv_to_bridge_state(bridge->base.state);
> +
> + tc->output_bus_fmt = state->output_bus_cfg.format;
>
> mode = >encoder->crtc->state->adjusted_mode;
>
> @@ -451,14 +455,13 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> d2l_write(tc->i2c, LVPHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_ND(6));
>
> dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
> - connector->display_info.bus_formats[0],
> + tc->output_bus_fmt,
> tc->bpc);
> /*
>* Default hardware register settings of tc358775 configured
>* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
>*/
> - if (connector->display_info.bus_formats[0] ==
> - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
> + if (tc->output_bus_fmt == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
As output_bus_fmt is only used in this function, I would make this a
local variable and drop the output_bus_fmt field from tc_data. You could
even use state->output_bus_cfg.format directly in the two locations
where the value is needed without a local variable, up to you.
> /* VESA-24 */
> d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
> LVI_R3));
> d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5,
> LVI_G0));
> @@ -590,6 +593,40 @@ static int tc358775_parse_dt(struct device_node *np,
> struct tc_data *tc)
> return 0;
> }
>
> +static u32 *
> +tc_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state,
> + u32 output_fmt,
> + unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts = NULL;
> + u8 i;
You can make this an unsigned int, a u8 won't save space of CPU time.
> +
> + *num_input_fmts = 0;
> +
> + for (i = 0 ; i
Re: [PATCH v4 4/5] mm: Fix page reference leak in soft_offline_page()
On Wed, Jan 13, 2021 at 5:50 PM HORIGUCHI NAOYA(堀口 直也)
wrote:
>
> On Wed, Jan 13, 2021 at 04:43:32PM -0800, Dan Williams wrote:
> > The conversion to move pfn_to_online_page() internal to
> > soft_offline_page() missed that the get_user_pages() reference taken by
> > the madvise() path needs to be dropped when pfn_to_online_page() fails.
> > Note the direct sysfs-path to soft_offline_page() does not perform a
> > get_user_pages() lookup.
> >
> > When soft_offline_page() is handed a pfn_valid() &&
> > !pfn_to_online_page() pfn the kernel hangs at dax-device shutdown due to
> > a leaked reference.
> >
> > Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn")
> > Cc: Andrew Morton
> > Cc: Naoya Horiguchi
> > Cc: Michal Hocko
> > Reviewed-by: David Hildenbrand
> > Reviewed-by: Oscar Salvador
> > Cc:
> > Signed-off-by: Dan Williams
>
> I'm OK if we don't have any other better approach, but the proposed changes
> make code a little messy, and I feel that get_user_pages() might be the
> right place to fix. Is get_user_pages() expected to return struct page with
> holding refcount for offline valid pages? I thought that such pages are
> only used by drivers for dax-devices, but that might be wrong. Can I ask for
> a little more explanation from this perspective?
The motivation for ZONE_DEVICE is to allow get_user_pages() for "offline" pfns.
soft_offline_page() wants to only operate on "online" pfns.
get_user_pages() on a dax-mapping returns an "offline" ZONE_DEVICE page.
When pfn_to_online_page() fails the get_user_pages() reference needs
to be dropped.
To be honest I dislike the entire flags based scheme for communicating
the fact that page reference obtained by madvise needs to be dropped
later. I'd rather pass a non-NULL 'struct page *' than redo
pfn_to_page() conversions in the leaf functions, but that's a much
larger change.
lib/llist.c:33:11: warning: converting the result of '<<' to a boolean always evaluates to true
Hi Nathan, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: afe956c577b2d5a3d9834e4424587c1ebcf90c4c kbuild: Enable -Wtautological-compare date: 9 months ago config: mips-randconfig-r026-20210114 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 68ff52ffead2ba25cca442778ab19286000daad7) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install mips cross compiling tool for clang build # apt-get install binutils-mips-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=afe956c577b2d5a3d9834e4424587c1ebcf90c4c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout afe956c577b2d5a3d9834e4424587c1ebcf90c4c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from include/linux/llist.h:51: In file included from include/linux/atomic.h:7: arch/mips/include/asm/atomic.h:49:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] arch/mips/include/asm/atomic.h:40:9: note: expanded from macro 'ATOMIC_OPS' return cmpxchg(>counter, o, n); \ ^ arch/mips/include/asm/cmpxchg.h:204:7: note: expanded from macro 'cmpxchg' if (!__SYNC_loongson3_war) \ ^ arch/mips/include/asm/sync.h:147:34: note: expanded from macro '__SYNC_loongson3_war' # define __SYNC_loongson3_war (1 << 31) ^ In file included from lib/llist.c:15: In file included from include/linux/llist.h:51: In file included from include/linux/atomic.h:7: arch/mips/include/asm/atomic.h:49:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] arch/mips/include/asm/atomic.h:45:9: note: expanded from macro 'ATOMIC_OPS' return xchg(>counter, n);\ ^ arch/mips/include/asm/cmpxchg.h:102:7: note: expanded from macro 'xchg' if (!__SYNC_loongson3_war) \ ^ arch/mips/include/asm/sync.h:147:34: note: expanded from macro '__SYNC_loongson3_war' # define __SYNC_loongson3_war (1 << 31) ^ In file included from lib/llist.c:15: In file included from include/linux/llist.h:51: In file included from include/linux/atomic.h:7: arch/mips/include/asm/atomic.h:53:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] ATOMIC_OPS(atomic64, s64) ^ arch/mips/include/asm/atomic.h:40:9: note: expanded from macro 'ATOMIC_OPS' return cmpxchg(>counter, o, n); \ ^ arch/mips/include/asm/cmpxchg.h:194:7: note: expanded from macro 'cmpxchg' if (!__SYNC_loongson3_war) \ ^ arch/mips/include/asm/sync.h:147:34: note: expanded from macro '__SYNC_loongson3_war' # define __SYNC_loongson3_war (1 << 31) ^ In file included from lib/llist.c:15: In file included from include/linux/llist.h:51: In file included from include/linux/atomic.h:7: arch/mips/include/asm/atomic.h:53:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] arch/mips/include/asm/atomic.h:40:9: note: expanded from macro 'ATOMIC_OPS' return cmpxchg(>counter, o, n); \ ^ arch/mips/include/asm/cmpxchg.h:204:7: note: expanded from macro 'cmpxchg' if (!__SYNC_loongson3_war) \ ^ arch/mips/include/asm/sync.h:147:34: note: expanded from macro '__SYNC_loongson3_war' # define __SYNC_loongson3_war (1 << 31) ^ In file included from lib/llist.c:15: In file included from include/linux/llist.h:51: In file included from include/linux/atomic.h:7: arch/mips/include/asm/atomic.h:53:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] arch/mips/include/asm/atomic.h:45:9: note: expanded from macro 'ATOMIC_OPS' return
Re: [PATCH v6 5/5] media: i2c: max9286: Configure reverse channel amplitude
Hi Jacopo,
On Tue, Jan 12, 2021 at 10:08:05AM +0100, Jacopo Mondi wrote:
> On Tue, Jan 12, 2021 at 07:03:42AM +0200, Laurent Pinchart wrote:
> > On Mon, Jan 11, 2021 at 12:20:23PM +0100, Jacopo Mondi wrote:
> > > On Mon, Jan 11, 2021 at 12:58:59PM +0200, Laurent Pinchart wrote:
> > > > On Mon, Jan 11, 2021 at 11:43:11AM +0100, Jacopo Mondi wrote:
> > > >> On Wed, Dec 16, 2020 at 07:22:17PM +0200, Laurent Pinchart wrote:
> > > >>> On Tue, Dec 15, 2020 at 06:09:57PM +0100, Jacopo Mondi wrote:
> > > Adjust the initial reverse channel amplitude parsing from
> > > firmware interface the 'maxim,reverse-channel-microvolt'
> > > property.
> > >
> > > This change is required for both rdacm20 and rdacm21 camera
> > > modules to be correctly probed when used in combination with
> > > the max9286 deserializer.
> > >
> > > Reviewed-by: Kieran Bingham
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/media/i2c/max9286.c | 23 ++-
> > > 1 file changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/max9286.c
> > > b/drivers/media/i2c/max9286.c
> > > index 021309c6dd6f..9b40a4890c4d 100644
> > > --- a/drivers/media/i2c/max9286.c
> > > +++ b/drivers/media/i2c/max9286.c
> > > @@ -163,6 +163,8 @@ struct max9286_priv {
> > > unsigned int mux_channel;
> > > bool mux_open;
> > >
> > > +u32 reverse_channel_mv;
> > > +
> > > struct v4l2_ctrl_handler ctrls;
> > > struct v4l2_ctrl *pixelrate;
> > >
> > > @@ -557,10 +559,14 @@ static int max9286_notify_bound(struct
> > > v4l2_async_notifier *notifier,
> > > * All enabled sources have probed and enabled their reverse
> > > control
> > > * channels:
> > > *
> > > + * - Increase the reverse channel amplitude to compensate for
> > > the
> > > + * remote ends high threshold, if not done already
> > > * - Verify all configuration links are properly detected
> > > * - Disable auto-ack as communication on the control channel
> > > are now
> > > * stable.
> > > */
> > > +if (priv->reverse_channel_mv < 170)
> > > +max9286_reverse_channel_setup(priv, 170);
> > > >>>
> > > >>> I'm beginning to wonder if there will be a need in the future to not
> > > >>> increase the reverse channel amplitude (keeping the threshold low on
> > > >>> the
> > > >>> remote side). An increased amplitude increases power consumption, and
> > > >>> if
> > > >>> the environment isn't noisy, a low amplitude would work. The device
> > > >>> tree
> > > >>> would then need to specify both the initial amplitude required by the
> > > >>> remote side, and the desired amplitude after initialization. What do
> > > >>> you
> > > >>> think ? Is it overkill ? We don't have to implement this now, so
> > > >>>
> > > >>> Reviewed-by: Laurent Pinchart
> > > >>>
> > > >>> but if this feature could be required later, we may want to take into
> > > >>> account in the naming of the new DT property to reflect the fact that
> > > >>> it
> > > >>> is the initial value.
> > > >>
> > > >> I had the same thought when I initially proposed
> > > >> "maxim,initial-reverse-channel-mV"
> > > >>
> > > >> Having to use the standard unit suffix that would have become
> > > >> "maxim,initial-reverse-channel-microvolt"
> > > >> which is extremely long.
> > > >>
> > > >> I can't tell if there will be any need to adjust the amplitude later.
> > > >> In any case, I would not rely on a DTS property to do so, as once we
> > > >> have probed the remote we have a subdev where to call
> > > >> 'get_mbus_config()' on, and from there we can report the high threshold
> > > >> status of the serializer and adjust the deser amplitude accordingly.
> > > >
> > > > I don't think that's the point. The threshold of the serializer is
> > > > something we can configure at runtime. What voltage level to use after
> > >
> > > How so ? I mean, we can add an API for this, but currently it's
> > > configured at probe time and that's it. Its configuration might as
> > > well come from a DT property like we do on the deserializer here but I
> > > fail to see why it's different. Both settings depends on the required
> > > noise immunity of th system.
> >
> > The voltage level configuration need to match between the tserializer
> > (transmitter) and the deserializer (receiver). The serializer is
> > configured with a voltage level, and the deserializer needs to be
> > configured with a corresponding threshold.
>
> If I'm not mistaken it's actually the other way around, at least for
> the chips we're dealing with.
Yes, I mixed up the direction, sorry about that.
> The serializer (MAX9271) has an "Reverse Channel Receiver High
> Threshold Enable" bit (register 0x08[0]) undocumented in the chip
> manual
[PATCH] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols
clang-12 -fno-pic (since https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6) can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail` on x86. The two forms should have identical behaviors on x86-64 but the former causes GNU as<2.37 to produce an unreferenced undefined symbol _GLOBAL_OFFSET_TABLE_. (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the linker behavior is identical as far as Linux kernel is concerned.) Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for external function calls on x86. Note: ld -z defs and dynamic loaders do not error for unreferenced undefined symbols so the module loader is reading too much. If we ever need to ignore more symbols, the code should be refactored to ignore unreferenced symbols. Reported-by: Marco Elver Link: https://github.com/ClangBuiltLinux/linux/issues/1250 Signed-off-by: Fangrui Song --- kernel/module.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index 4bf30e4b3eaa..2e2deea99289 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2395,8 +2395,14 @@ static int simplify_symbols(struct module *mod, const struct load_info *info) break; } - /* Ok if weak. */ - if (!ksym && ELF_ST_BIND(sym[i].st_info) == STB_WEAK) + /* Ok if weak. Also allow _GLOBAL_OFFSET_TABLE_: +* GNU as before 2.37 produces an unreferenced _GLOBAL_OFFSET_TABLE_ +* for call foo@PLT on x86-64. If the code ever needs to ignore +* more symbols, refactor the code to only warn if referenced by +* a relocation. +*/ + if (!ksym && (ELF_ST_BIND(sym[i].st_info) == STB_WEAK || + !strcmp(name, "_GLOBAL_OFFSET_TABLE_"))) break; ret = PTR_ERR(ksym) ?: -ENOENT; -- 2.30.0.284.gd98b1dd5eaa7-goog
Re: [PATCH v4 2/2] Input: cros-ec-keyb - Expose function row physical map to userspace
On Wed, Jan 13, 2021 at 5:39 PM Stephen Boyd wrote: > > Quoting Philip Chen (2021-01-13 17:29:05) > > On Wed, Jan 13, 2021 at 3:14 PM Stephen Boyd wrote: > > > > > > Quoting Philip Chen (2021-01-13 14:47:18) > > > > On Tue, Jan 12, 2021 at 10:49 PM Stephen Boyd > > > > wrote: > > > > > > > > > > Quoting Philip Chen (2021-01-12 15:55:28) > > > > > > On Mon, Jan 11, 2021 at 6:24 PM Stephen Boyd > > > > > > wrote: > > > > > > > > > > > > > > Is it documented in Documentation/ABI/? > > > > > > Not yet. > > > > > > Is it proper to add the documentation to > > > > > > `testing/sysfs-driver-input-keyboard`? > > > > > > > > > > Somewhere in testing is fine. I'm not sure if it is a generic proprty > > > > > for all keyboards though? What's the path in sysfs? > > > > I wouldn't say it's generic. > > > > It is available in the keyboard device node only when the board has a > > > > custom top-row keyboard design. > > > > The path in sysfs is something like: > > > > /sys/class/input/input0/device/function_row_physmap, where input0 is > > > > cros_ec. > > > > > > I see that atkbd already has this so at least it would be common to some > > > sort of keyboard device. I'm not sure where to document it though. I see > > > that atkbd has a handful of undocumented sysfs attributes so adding all > > > of those may lead to a common path. At the least it sounds OK to have a > > > sysfs-driver-input-keyboard file if input folks are OK with it. > > Since there are other undocumented sysfs attributes for input/keyboard > > anyway, we should probably leave the documentation to another patch? > > For now, let's move to patch v5, where I've addressed all of the > > comments so far. > > Please document this one that's being introduced. We should document all > the sysfs attributes but we don't always do a good job at it. OK, will do!
Re: [PATCH v5 1/2] dt-bindings: input: cros-ec-keyb: Add a new property
On Wed, Jan 13, 2021 at 5:30 PM Stephen Boyd wrote: > > Quoting Philip Chen (2021-01-13 17:25:12) > > This patch adds a new property `function-row-physmap` to the > > :) Sorry, I'll make it imperative tense. > > > device tree for the custom keyboard top row design. > > > > The property describes the rows/columns of the top row keys > > from left to right. > > > > Signed-off-by: Philip Chen > > --- > > > > Changes in v5: > > - add minItems and maxItems for `function-row-physmap` > > > > Changes in v2: > > - add `function-row-physmap` instead of `google,custom-keyb-top-row` > > > > .../bindings/input/google,cros-ec-keyb.yaml | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > index 8e50c14a9d778..e573ef3e58b65 100644 > > --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml > > @@ -31,6 +31,18 @@ properties: > >if the EC does not have its own logic or hardware for this. > > type: boolean > > > > + function-row-physmap: > > +$ref: '/schemas/types.yaml#/definitions/uint32-array' > > I'm not sure this is needed if min/max items is there. > > > +minItems: 1 > > +maxItems: 15 > > +description: | > > + An ordered u32 array describing the rows/columns (in the scan matrix) > > + of top row keys from physical left (KEY_F1) to right. Each entry > > + encodes the row/column as: > > + (((row) & 0xFF) << 24) | (((column) & 0xFF) << 16) > > + where the lower 16 bits are reserved. This property is specified only > > + when the keyboard has a custom design for the top row keys. > > Can you add it to the example so it can be tested? Then you can prove > out if the ref is needed or not. Sure, I'll give it a try. > > > + > > required: > >- compatible > >
linux-next: Tree for Jan 14
Hi all,
Changes since 20210113:
The drm tree still had its build failure so I used the version from
next-20210107.
The drm-intel tree still had its build failure from merging the drm tree,
so I have used the version from next-20210108.
The drm-misc tree lost its build failure, but gained another so I have
used the version from next-20210107.
The tip tree gained a build failure for which I reverted a commit.
I reverted a commit from the iomem-mmap-vs-gup tree that caused a boot
failure on PowerPC.
Non-merge commits (relative to Linus' tree): 2617
2754 files changed, 115279 insertions(+), 40541 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 331 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (65f0d2414b70 Merge tag 'sound-5.11-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (5625dcfbbcf8 Documentation: kbuild: Fix section
reference)
Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (1f1244a5ddb7 compiler.h: Raise minimum
version of GCC to 5.1 for arm64)
Merging arm-soc-fixes/arm/fixes (bac717171971 ARM: picoxcell: fix missing
interrupt-parent properties)
Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (3ce47d95b734 powerpc: Handle
.text.{hot,unlikely}.* in linker script)
Merging s390-fixes/fixes (a1a322a62dba s390/vfio-ap: clean up vfio_ap resources
when KVM pointer invalidated)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (a95d25dd7b94 rxrpc: Call state should be read with
READ_ONCE() under some circumstances)
Merging bpf/master (b8d52264df85 libbpf: Allow loading empty BTFs)
Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in
xfrm_policy_addr_delta())
Merging netfilter/master (c8a8ead01736 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (869f4fdaf4ca netfilter: nf_nat: Fix memleak in nf_nat_init)
Merging wireless-drivers/master (6279d812eab6 Merge tag 'net-5.11-rc3-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging mac80211/master (51d62f2f2c50 cfg80211: Save the regulatory domain with
a lock)
Merging rdma-fixes/for-rc (f2bc3af6353c RDMA/ocrdma: Fix use after free in
ocrdma_dealloc_ucontext_pd())
Merging sound-current/for-linus (5e941fc033e4 ALSA: hda: Add AlderLake-P PCI ID
and HDMI codec vid)
Merging sound-asoc-fixes/for-linus (530aef25e6ad Merge remote-tracking branch
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (72962ebcdd45 Merge remote-tracking branch
'regmap/for-5.11' into regmap-linus)
Merging regulator-fixes/for-linus (17f953176384 Merge remote-tracking branch
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (7c53f6b671f4 Linux 5.11-rc3)
Merging pci-current/for-linus (7c53f6b671f4 Linux 5.11
Re: madvise(MADV_REMOVE) deadlocks on shmem THP
On (21/01/13 20:31), Hugh Dickins wrote:
> > We are running into lockups during the memory pressure tests on our
> > boards, which essentially NMI panic them. In short the test case is
> >
> > - THP shmem
> > echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled
> >
> > - And a user-space process doing madvise(MADV_HUGEPAGE) on new mappings,
> > and madvise(MADV_REMOVE) when it wants to remove the page range
> >
> > The problem boils down to the reverse locking chain:
> > kswapd does
> >
> > lock_page(page) -> down_read(page->mapping->i_mmap_rwsem)
> >
> > madvise() process does
> >
> > down_write(page->mapping->i_mmap_rwsem) -> lock_page(page)
> >
> >
> >
> > CPU0 CPU1
> >
> > kswapd vfs_fallocate()
> > shrink_node()
> > shmem_fallocate()
> > shrink_active_list()
> > unmap_mapping_range()
> >page_referenced() << lock page:PG_locked >>
> > unmap_mapping_pages() << down_write(mapping->i_mmap_rwsem) >>
> > rmap_walk_file()
> > zap_page_range_single()
> > down_read(mapping->i_mmap_rwsem) << W-locked on CPU1>>
> > unmap_page_range()
> > rwsem_down_read_failed()
> > __split_huge_pmd()
> >__rwsem_down_read_failed_common()
> > __lock_page() << PG_locked on CPU0 >>
> > schedule()
> > wait_on_page_bit_common()
> >
> > io_schedule()
>
> Very interesting, Sergey: many thanks for this report.
Thanks for the quick feedback.
> There is no doubt that kswapd is right in its lock ordering:
> __split_huge_pmd() is in the wrong to be attempting lock_page().
>
> Which used not to be done, but was added in 5.8's c444eb564fb1 ("mm:
> thp: make the THP mapcount atomic against __split_huge_pmd_locked()").
Hugh, I forgot to mention, we are facing these issues on 4.19.
Let me check if (maybe) we have cherry picked c444eb564fb1.
-ss
powerpc64-linux-ld: warning: orphan section `.stubs' from `drivers/net/ethernet/cavium/liquidio/lio_ethtool.o' being placed in section `.stubs'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: 85d33df357b634649ddbe0a20fd2d0fc5732c3cb bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS date: 1 year ago config: powerpc64-randconfig-r001-20210113 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=85d33df357b634649ddbe0a20fd2d0fc5732c3cb git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 85d33df357b634649ddbe0a20fd2d0fc5732c3cb # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/devices/pmc551.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/devices/mtd_dataflash.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/devices/mchp23k256.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/devices/sst25l.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/nand/onenand/onenand_base.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/nand/onenand/onenand_bbt.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/mtd/hyperbus/hyperbus-core.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-mem.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-bitbang.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-cadence.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-dw.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-fsl-espi.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-mxic.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-oc-tiny.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-rockchip.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-sc18is602.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-tle62x0.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/spi/spi-xcomm.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/mii.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/Space.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/loopback.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/phy/mdio-boardinfo.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/phy/phylink.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/phy/phy.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/phy/phy-c45.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/phy/phy-core.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan section `.ctors.65435' from `drivers/net/phy/phy_device.o' being placed in section `.ctors.65435' powerpc64-linux-ld: warning: orphan s
Re: [PATCH] crypto: keembay - CRYPTO_DEV_KEEMBAY_OCS_HCU should depend on ARCH_KEEMBAY
On Tue, Jan 12, 2021 at 05:15:40PM +0100, Geert Uytterhoeven wrote:
> The Intel Keem Bay Offload and Crypto Subsystem (OCS) Hash Control Unit
> (HCU) is only present on Intel Keem Bay SoCs. Hence add a dependency on
> ARCH_KEEMBAY, to prevent asking the user about this driver when
> configuring a kernel without Intel Keem Bay platform support.
>
> Fixes: 472b0cd39e16 ("crypto: keembay - Add Keem Bay OCS HCU driver")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/crypto/keembay/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
There is already a patch in the queue that fixes this.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
i2c-sprd.c:(.text.sprd_i2c_probe+0x258): undefined reference to `clk_set_parent'
Hi Krzysztof, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: 4a2d5f663dab6614772d8e28ca190b127ba46d9d i2c: Enable compile testing for more drivers date: 12 months ago config: mips-randconfig-r015-20210113 (attached as .config) compiler: mipsel-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a2d5f663dab6614772d8e28ca190b127ba46d9d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 4a2d5f663dab6614772d8e28ca190b127ba46d9d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mipsel-linux-ld: drivers/i2c/busses/i2c-sprd.o: in function `sprd_i2c_probe': >> i2c-sprd.c:(.text.sprd_i2c_probe+0x258): undefined reference to >> `clk_set_parent' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v5 0/5] Unify NUMA implementation between ARM64 & RISC-V
On Mon, 11 Jan 2021 11:31:11 PST (-0800), ati...@atishpatra.org wrote: On Sat, Jan 9, 2021 at 12:51 PM Palmer Dabbelt wrote: On Sun, 13 Dec 2020 17:02:19 PST (-0800), ati...@atishpatra.org wrote: > On Wed, Nov 18, 2020 at 4:39 PM Atish Patra wrote: >> >> This series attempts to move the ARM64 numa implementation to common >> code so that RISC-V can leverage that as well instead of reimplementing >> it again. >> >> RISC-V specific bits are based on initial work done by Greentime Hu [1] but >> modified to reuse the common implementation to avoid duplication. >> >> [1] https://lkml.org/lkml/2020/1/10/233 >> >> This series has been tested on qemu with numa enabled for both RISC-V & ARM64. >> It would be great if somebody can test it on numa capable ARM64 hardware platforms. >> This patch series doesn't modify the maintainers list for the common code (arch_numa) >> as I am not sure if somebody from ARM64 community or Greg should take up the >> maintainership. Ganapatrao was the original author of the arm64 version. >> I would be happy to update that in the next revision once it is decided. >> >> # numactl --hardware >> available: 2 nodes (0-1) >> node 0 cpus: 0 1 2 3 >> node 0 size: 486 MB >> node 0 free: 470 MB >> node 1 cpus: 4 5 6 7 >> node 1 size: 424 MB >> node 1 free: 408 MB >> node distances: >> node 0 1 >> 0: 10 20 >> 1: 20 10 >> # numactl -show >> policy: default >> preferred node: current >> physcpubind: 0 1 2 3 4 5 6 7 >> cpubind: 0 1 >> nodebind: 0 1 >> membind: 0 1 >> >> The patches are also available at >> https://github.com/atishp04/linux/tree/5.11_numa_unified_v5 >> >> For RISC-V, the following qemu series is a pre-requisite(already available in upstream) >> https://patchwork.kernel.org/project/qemu-devel/list/?series=303313 >> >> Testing: >> RISC-V: >> Tested in Qemu and 2 socket OmniXtend FPGA. >> >> ARM64: >> 2 socket kunpeng920 (4 nodes around 250G a node) >> Tested-by: Jonathan Cameron >> >> Changes from v4->v5: >> 1. Added by Acked-by & Reviewed-by tags. >> 2. Swapped patch 1 & 2 in v4 version. >> >> Changes from v3->v4: >> 1. Removed redundant duplicate header. >> 2. Added Reviewed-by tags. >> >> Changes from v2->v3: >> 1. Added Acked-by/Reviewed-by tags. >> 2. Replaced asm/acpi.h with linux/acpi.h >> 3. Defined arch_acpi_numa_init as static. >> >> Changes from v1->v2: >> 1. Replaced ARM64 specific compile time protection with ACPI specific ones. >> 2. Dropped common pcibus_to_node changes. Added required changes in RISC-V. >> 3. Fixed few typos. >> >> Atish Patra (4): >> arm64, numa: Change the numa init functions name to be generic >> numa: Move numa implementation to common code >> riscv: Separate memory init from paging init >> riscv: Add numa support for riscv64 platform >> >> Greentime Hu (1): >> riscv: Add support pte_protnone and pmd_protnone if >> CONFIG_NUMA_BALANCING >> >> arch/arm64/Kconfig| 1 + >> arch/arm64/include/asm/numa.h | 48 + >> arch/arm64/kernel/acpi_numa.c | 12 - >> arch/arm64/mm/Makefile| 1 - >> arch/arm64/mm/init.c | 4 +- >> arch/riscv/Kconfig| 31 ++- >> arch/riscv/include/asm/mmzone.h | 13 + >> arch/riscv/include/asm/numa.h | 8 +++ >> arch/riscv/include/asm/pci.h | 14 + >> arch/riscv/include/asm/pgtable.h | 21 >> arch/riscv/kernel/setup.c | 11 +++- >> arch/riscv/kernel/smpboot.c | 12 - >> arch/riscv/mm/init.c | 10 +++- >> drivers/base/Kconfig | 6 +++ >> drivers/base/Makefile | 1 + >> .../mm/numa.c => drivers/base/arch_numa.c | 27 -- >> include/asm-generic/numa.h| 52 +++ >> 17 files changed, 200 insertions(+), 72 deletions(-) >> create mode 100644 arch/riscv/include/asm/mmzone.h >> create mode 100644 arch/riscv/include/asm/numa.h >> rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (96%) >> create mode 100644 include/asm-generic/numa.h >> >> -- >> 2.25.1 >> >> >> ___ >> linux-riscv mailing list >> linux-ri...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > Hey Palmer, > I did not see this series in for-next. Let me know if you need > anything else to be done for this series. Sorry about that. It's on for-next, with Randy's comment addressed. There was one merge conflict: we don't have resource_init() in for-next yet (which I think means I missed something else). resource_init is changed to init_resource and moved to setup.c in the following patch which was merged in 5.11 MW. 00ab027a3b82 RISC-V: Add kernel image sections to the resource tree Ah, great, for some reason I thought we hadn't merged those yet. IDK if that's necessary for the NUMA
Re: [PATCH] nvme: reject the ns when the block size is smaller than a sector
Sagi Grimberg 于2021年1月14日周四 上午6:13写道：
>
>
> >> The nvme spec(1.4a, figure 248) says:
> >> "A value smaller than 9 (i.e., 512 bytes) is not supported."
> >>
> >> Signed-off-by: Li Feng
> >> ---
> >> drivers/nvme/host/core.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> >> index f320273fc672..1f02e6e49a05 100644
> >> --- a/drivers/nvme/host/core.c
> >> +++ b/drivers/nvme/host/core.c
> >> @@ -2161,6 +2161,12 @@ static int nvme_update_ns_info(struct nvme_ns *ns,
> >> struct nvme_id_ns *id)
> >>
> >> blk_mq_freeze_queue(ns->disk->queue);
> >> ns->lba_shift = id->lbaf[lbaf].ds;
> >> +if (ns->lba_shift < 9) {
> >> +pr_warn("%s: bad lba_shift(%d)\n", ns->disk->disk_name,
> >> ns->lba_shift);
> >> +ret = -1;
>
> Meaningful errno would be useful. Also better to use dev_warn
>
> >> +goto out_unfreeze;
> >> +}
> >> +
> >> nvme_set_queue_limits(ns->ctrl, ns->queue);
> >>
> >> if (ns->head->ids.csi == NVME_CSI_ZNS) {
> >>
> >
> >
> > But this only catches a physical block size < 512 for NVMe, not any other
> > block device.
> >
> > Please fix it for the general case in blk_queue_physical_block_size().
>
> We actually call that later and would probably be better to check here..
Thanks for your comments.
The prototype is:
void blk_queue_logical_block_size(struct request_queue *, unsigned int);
So change it to:
bool blk_queue_logical_block_size(struct request_queue *, unsigned int);
And check all callers of this function, right?
Re: [PATCH 0/4] Assorted fixes for RV32
On Wed, 13 Jan 2021 21:09:36 PST (-0800), Palmer Dabbelt wrote: On Thu, 07 Jan 2021 01:26:48 PST (-0800), Atish Patra wrote: This series fixes various issues observed in latest kernel on RV32. The first two patches fixes an resource tree introduced in 5.11-rc1 while the last two fixes the case where 2GB physical memory is used on RV32. There are may be better way to fix the issue pointed out in PATCH 3 as it seems a generic kernel issue where kernel pointers can not use last 4k of addressable memory. I am open to other better alternate suggestions. Atish Patra (4): RISC-V: Do not allocate memblock while iterating reserved memblocks RISC-V: Set current memblock limit RISC-V: Fix L1_CACHE_BYTES for RV32 RISC-V: Fix maximum allowed phsyical memory for RV32 arch/riscv/Kconfig | 6 -- arch/riscv/include/asm/cache.h | 4 arch/riscv/kernel/setup.c | 24 +--- arch/riscv/mm/init.c | 16 ++-- 4 files changed, 35 insertions(+), 15 deletions(-) I took all of them but that L1_CACHE_BYTES one, which I had a comment on. Thanks! Oops, I just saw the v2. I took those instead, the comment still applies.
Re: [PATCH 0/4] Assorted fixes for RV32
On Thu, 07 Jan 2021 01:26:48 PST (-0800), Atish Patra wrote: This series fixes various issues observed in latest kernel on RV32. The first two patches fixes an resource tree introduced in 5.11-rc1 while the last two fixes the case where 2GB physical memory is used on RV32. There are may be better way to fix the issue pointed out in PATCH 3 as it seems a generic kernel issue where kernel pointers can not use last 4k of addressable memory. I am open to other better alternate suggestions. Atish Patra (4): RISC-V: Do not allocate memblock while iterating reserved memblocks RISC-V: Set current memblock limit RISC-V: Fix L1_CACHE_BYTES for RV32 RISC-V: Fix maximum allowed phsyical memory for RV32 arch/riscv/Kconfig | 6 -- arch/riscv/include/asm/cache.h | 4 arch/riscv/kernel/setup.c | 24 +--- arch/riscv/mm/init.c | 16 ++-- 4 files changed, 35 insertions(+), 15 deletions(-) I took all of them but that L1_CACHE_BYTES one, which I had a comment on. Thanks!
Re: [PATCH 3/4] RISC-V: Fix L1_CACHE_BYTES for RV32
On Thu, 07 Jan 2021 01:26:51 PST (-0800), Atish Patra wrote: SMP_CACHE_BYTES/L1_CACHE_BYTES should be defined as 32 instead of 64 for RV32. Otherwise, there will be hole of 32 bytes with each memblock allocation if it is requested to be aligned with SMP_CACHE_BYTES. Signed-off-by: Atish Patra --- arch/riscv/include/asm/cache.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h index 9b58b104559e..c9c669ea2fe6 100644 --- a/arch/riscv/include/asm/cache.h +++ b/arch/riscv/include/asm/cache.h @@ -7,7 +7,11 @@ #ifndef _ASM_RISCV_CACHE_H #define _ASM_RISCV_CACHE_H +#ifdef CONFIG_64BIT #define L1_CACHE_SHIFT 6 +#else +#define L1_CACHE_SHIFT 5 +#endif #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) Should we not instead just #define SMP_CACHE_BYTES L1_CACHE_BYTES like a handful of architectures do? The cache size is sort of fake here, as we don't have any non-coherent mechanisms, but IIRC we wrote somewhere that it's recommended to have 64-byte cache lines in RISC-V implementations as software may assume that for performance reasons. Not really a strong reason, but I'd prefer to just make these match.
Re: [PATCH v6 2/4] scmi-cpufreq: Move CPU initialisation to probe
On 13-01-21, 11:55, Nicola Mazzucato wrote:
> On 1/12/21 11:17 AM, Viresh Kumar wrote:
> > This could have been done with a per-cpu variable instead.
>
> sure, I can do a DEFINE_PER_CPU() for it if it makes it better.
If we don't go with the linked list approach, then yes.
> >> + for_each_possible_cpu(cpu) {
> >> + if (!zalloc_cpumask_var(_table[cpu].scmi_shared_cpus,
> >> + GFP_KERNEL))
> >> + goto out;
> >> + }
> >
> > You are making a copy of the struct for each CPU and so for a 16 CPUs
> > sharing their clock lines, you will have 16 copies of the exact same
> > stuff.
> >
> > An optimal approach would be to have a linked-list of this structure
> > and that will only have 1 node per cpufreq policy.
>
> It is allocating space for the cpumask for each of the cpu. No data is copied
> yet.
Yes, I was talking about the whole design here.
> I understand the optimisation, but I don't see a linkage to cpufreq policy to
> be
> a good idea. This cpudata is for internal storage of scmi and opp-shared info
> and it is not tied to cpufreq policy.
Well, it is going to be the same information for all CPUs of a policy, isn't it
?
> We have moved all the cpu bits to probe
> and at this stage we have no knowledge of cpufreq polices.
Yes, but you are reading that information from scmi or DT (empty opp tables) and
so you know what the cpumasks are going to be set to. The linked list is the
right solution in my opinion, it is much more optimal.
> >> +static int scmi_init_device(const struct scmi_handle *handle, int cpu)
> >> +{
> >> + struct device *cpu_dev;
> >> + int ret, nr_opp;
> >> + struct em_data_callback em_cb = EM_DATA_CB(scmi_get_cpu_power);
> >> + bool power_scale_mw;
> >> + cpumask_var_t scmi_cpus;
> >> +
> >> + if (!zalloc_cpumask_var(_cpus, GFP_KERNEL))
> >> + return -ENOMEM;
> >> +
> >> + cpumask_set_cpu(cpu, scmi_cpus);
> >> +
> >> + cpu_dev = get_cpu_device(cpu);
> >> +
> >> + ret = scmi_get_sharing_cpus(cpu_dev, scmi_cpus);
> >
> > Where do you expect the sharing information to come from in this case
> > ? DT ?
>
> Coming from SCMI perf. The source of info has not changed.
>
> >
> >> + if (ret) {
> >> + dev_warn(cpu_dev, "failed to get sharing cpumask\n");
> >> + goto free_cpumask;
> >> + }
> >> +
> >> + /*
> >> + * We get here for each CPU. Add OPPs only on those CPUs for which we
> >> + * haven't already done so, or set their OPPs as shared.
> >> + */
> >> + nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> >> + if (nr_opp <= 0) {
> >> + ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
> >> + if (ret) {
> >> + dev_warn(cpu_dev, "failed to add opps to the device\n");
> >> + goto free_cpumask;
> >> + }
> >> +
> >> + ret = dev_pm_opp_set_sharing_cpus(cpu_dev, scmi_cpus);
> >> + if (ret) {
> >> + dev_err(cpu_dev, "%s: failed to mark OPPs as shared:
> >> %d\n",
> >> + __func__, ret);
> >> + goto free_cpumask;
> >> + }
> >> +
> >> + nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> >
> > Shouldn't you do this just after adding the OPPs ?
>
> This was suggested earlier. It was moved closer to em_registration to where
> the
> nr_opp is used. One way or the other as I don't have a strong preference for
> its
> place.
It is better to move it above as this will shorten the error path.
--
viresh
Re: [PATCH 2/2] bdi: Use might_alloc()
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/mm-dmapool-Use-might_alloc/20210113-215207
base: git://git.cmpxchg.org/linux-mmotm.git master
config: openrisc-randconfig-r011-20210113 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/95ad71591084350229e768f9c2be5350d504f896
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Daniel-Vetter/mm-dmapool-Use-might_alloc/20210113-215207
git checkout 95ad71591084350229e768f9c2be5350d504f896
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=openrisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
mm/backing-dev.c: In function 'wb_get_create':
>> mm/backing-dev.c:647:2: error: implicit declaration of function
>> 'might_alloc'; did you mean 'might_lock'?
>> [-Werror=implicit-function-declaration]
647 | might_alloc(gfp);
| ^~~
| might_lock
cc1: some warnings being treated as errors
vim +647 mm/backing-dev.c
616
617 /**
618 * wb_get_create - get wb for a given memcg, create if necessary
619 * @bdi: target bdi
620 * @memcg_css: cgroup_subsys_state of the target memcg (must have
positive ref)
621 * @gfp: allocation mask to use
622 *
623 * Try to get the wb for @memcg_css on @bdi. If it doesn't exist, try
to
624 * create one. The returned wb has its refcount incremented.
625 *
626 * This function uses css_get() on @memcg_css and thus expects its
refcnt
627 * to be positive on invocation. IOW, rcu_read_lock() protection on
628 * @memcg_css isn't enough. try_get it before calling this function.
629 *
630 * A wb is keyed by its associated memcg. As blkcg implicitly enables
631 * memcg on the default hierarchy, memcg association is guaranteed to be
632 * more specific (equal or descendant to the associated blkcg) and thus
can
633 * identify both the memcg and blkcg associations.
634 *
635 * Because the blkcg associated with a memcg may change as blkcg is
enabled
636 * and disabled closer to root in the hierarchy, each wb keeps track of
637 * both the memcg and blkcg associated with it and verifies the blkcg on
638 * each lookup. On mismatch, the existing wb is discarded and a new
one is
639 * created.
640 */
641 struct bdi_writeback *wb_get_create(struct backing_dev_info *bdi,
642 struct cgroup_subsys_state
*memcg_css,
643 gfp_t gfp)
644 {
645 struct bdi_writeback *wb;
646
> 647 might_alloc(gfp);
648
649 if (!memcg_css->parent)
650 return >wb;
651
652 do {
653 rcu_read_lock();
654 wb = radix_tree_lookup(>cgwb_tree, memcg_css->id);
655 if (wb) {
656 struct cgroup_subsys_state *blkcg_css;
657
658 /* see whether the blkcg association has
changed */
659 blkcg_css = cgroup_get_e_css(memcg_css->cgroup,
660 _cgrp_subsys);
661 if (unlikely(wb->blkcg_css != blkcg_css ||
662 !wb_tryget(wb)))
663 wb = NULL;
664 css_put(blkcg_css);
665 }
666 rcu_read_unlock();
667 } while (!wb && !cgwb_create(bdi, memcg_css, gfp));
668
669 return wb;
670 }
671
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v2] perf test: Fix shadow stat test for non-bash shells
It was using some bash-specific features and failed to parse when
running with a different shell like below:
root@kbl-ppc:~/kbl-ws/perf-dev/lck-9077/acme.tmp/tools/perf# ./perf test 83
-vv
83: perf stat metrics (shadow stat) test:
--- start ---
test child forked, pid 3922
./tests/shell/stat+shadow_stat.sh: 19: ./tests/shell/stat+shadow_stat.sh: [[:
not found
./tests/shell/stat+shadow_stat.sh: 24: ./tests/shell/stat+shadow_stat.sh: [[:
not found
./tests/shell/stat+shadow_stat.sh: 30: ./tests/shell/stat+shadow_stat.sh: [[:
not found
(standard_in) 2: syntax error
./tests/shell/stat+shadow_stat.sh: 36: ./tests/shell/stat+shadow_stat.sh: [[:
not found
./tests/shell/stat+shadow_stat.sh: 19: ./tests/shell/stat+shadow_stat.sh: [[:
not found
./tests/shell/stat+shadow_stat.sh: 24: ./tests/shell/stat+shadow_stat.sh: [[:
not found
./tests/shell/stat+shadow_stat.sh: 30: ./tests/shell/stat+shadow_stat.sh: [[:
not found
(standard_in) 2: syntax error
./tests/shell/stat+shadow_stat.sh: 36: ./tests/shell/stat+shadow_stat.sh: [[:
not found
./tests/shell/stat+shadow_stat.sh: 45: ./tests/shell/stat+shadow_stat.sh:
declare: not found
test child finished with -1
end
perf stat metrics (shadow stat) test: FAILED!
Reported-by: Jin Yao
Signed-off-by: Namhyung Kim
---
tools/perf/tests/shell/stat+shadow_stat.sh | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/tools/perf/tests/shell/stat+shadow_stat.sh
b/tools/perf/tests/shell/stat+shadow_stat.sh
index 249dfe48cf6a..ebebd3596cf9 100755
--- a/tools/perf/tests/shell/stat+shadow_stat.sh
+++ b/tools/perf/tests/shell/stat+shadow_stat.sh
@@ -9,31 +9,29 @@ perf stat -a true > /dev/null 2>&1 || exit 2
test_global_aggr()
{
- local cyc
-
perf stat -a --no-big-num -e cycles,instructions sleep 1 2>&1 | \
grep -e cycles -e instructions | \
while read num evt hash ipc rest
do
# skip not counted events
- if [[ $num == "&1 | \
grep ^CPU | \
while read cpu num evt hash ipc rest
do
# skip not counted events
- if [[ $num == "
Re: [PATCH 1/1] usb: xhci: setup packets don't need DMA mapping
On 21-01-14 11:59:07, Daewoong Kim wrote:
> DMA mapping of urb->setup_packet is not necessary for xHCI host
> controllers. The xHCI specification says that Setup Stage TRB includes
> whole Setup Data; therefore, urb->setup_dma will not be used in the xhci
> HCD code.
>
How about bypass map/unmap operation for xHCI control transfer directly?
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 91ab81c3fc79..0a0ab14b7638 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1374,7 +1374,8 @@ static int xhci_map_urb_for_dma(struct usb_hcd *hcd,
struct urb *urb,
xhci = hcd_to_xhci(hcd);
- if (xhci_urb_suitable_for_idt(urb))
+ if (xhci_urb_suitable_for_idt(urb) ||
+ (usb_endpoint_xfer_control(>ep->desc)))
return 0;
if (xhci->quirks & XHCI_SG_TRB_CACHE_SIZE_QUIRK) {
@@ -1389,6 +1390,9 @@ static void xhci_unmap_urb_for_dma(struct usb_hcd *hcd,
struct urb *urb)
struct xhci_hcd *xhci;
bool unmap_temp_buf = false;
+ if (usb_endpoint_xfer_control(>ep->desc))
+ return;
+
xhci = hcd_to_xhci(hcd);
if (urb->num_sgs && (urb->transfer_flags & URB_DMA_MAP_SINGLE))
> Signed-off-by: Daewoong Kim
> ---
> drivers/usb/core/hcd.c | 4 +++-
> drivers/usb/host/xhci.c | 1 +
> include/linux/usb.h | 4
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index ad5a0f405a75..b1f9eac93f0d 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -1411,7 +1411,9 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
> urb *urb,
> if (usb_endpoint_xfer_control(>ep->desc)) {
> if (hcd->self.uses_pio_for_control)
> return ret;
> - if (hcd->localmem_pool) {
> + if (hcd->self.uses_pio_for_setup_pkt) {
> + ; /* do nothing */
> + } else if (hcd->localmem_pool) {
> ret = hcd_alloc_coherent(
> urb->dev->bus, mem_flags,
> >setup_dma,
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index e86940571b4c..c263aee82dc0 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -643,6 +643,7 @@ int xhci_run(struct usb_hcd *hcd)
>*/
>
> hcd->uses_new_polling = 1;
> + hcd->self.uses_pio_for_setup_pkt = 1;
> if (!usb_hcd_is_primary_hcd(hcd))
> return xhci_run_finished(xhci);
>
> diff --git a/include/linux/usb.h b/include/linux/usb.h
> index 7d72c4e0713c..76600e8de414 100644
> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -430,6 +430,10 @@ struct usb_bus {
>* Does the host controller use PIO
>* for control transfers?
>*/
> + u8 uses_pio_for_setup_pkt; /*
> + * Does the host controller use PIO
> + * for setup packets?
> + */
> u8 otg_port;/* 0, or number of OTG/HNP port */
> unsigned is_b_host:1; /* true during some HNP roleswitches */
> unsigned b_hnp_enable:1;/* OTG: did A-Host enable HNP? */
> --
> 2.17.1
>
--
Thanks,
Peter Chen
Re: [PATCH] of: unittest: Statically apply overlays using fdtoverlay
On 11-01-21, 09:46, Rob Herring wrote: > On Fri, Jan 8, 2021 at 2:41 AM Viresh Kumar wrote: > > > > Now that fdtoverlay is part of the kernel build, start using it to test > > the unitest overlays we have by applying them statically. > > Nice idea. > > > The file overlay_base.dtb have symbols of its own and we need to apply > > overlay.dtb to overlay_base.dtb alone first to make it work, which gives > > us intermediate-overlay.dtb file. > > Okay? If restructuring things helps we should do that. Frank? Frank, do we want to do something about it ? Maybe make overlay_base.dts an dtsi and include it from testcases.dts like the other ones ? -- viresh
Re: [PATCH v2 1/1] v4l: ioctl: Fix memory leak in video_usercopy
On 1/14/21 12:50 PM, Bingbu Cao wrote:
> Sakari,
>
> On 12/21/20 4:11 AM, Sakari Ailus wrote:
>> When an IOCTL with argument size larger than 128 that also used array
>> arguments were handled, two memory allocations were made but alas, only
>> the latter one of them was released. This happened because there was only
>> a single local variable to hold such a temporary allocation.
>>
>> Fix this by adding separate variables to hold the pointers to the
>> temporary allocations.
>>
>> Reported-by: Arnd Bergmann
>> Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
>> Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Sakari Ailus
>> Reviewed-by: Laurent Pinchart
>> ---
>> drivers/media/v4l2-core/v4l2-ioctl.c | 32
>> 1 file changed, 14 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 3198abdd538c..9906b41004e9 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -3283,7 +3283,7 @@ video_usercopy(struct file *file, unsigned int
>> orig_cmd, unsigned long arg,
>> v4l2_kioctl func)
>> {
>> charsbuf[128];
>> -void*mbuf = NULL;
>> +void*mbuf = NULL, *array_buf = NULL;
>> void*parg = (void *)arg;
>> longerr = -EINVAL;
>> boolhas_array_args;
>> @@ -3318,27 +3318,21 @@ video_usercopy(struct file *file, unsigned int
>> orig_cmd, unsigned long arg,
>> has_array_args = err;
>>
>> if (has_array_args) {
>> -/*
>> - * When adding new types of array args, make sure that the
>> - * parent argument to ioctl (which contains the pointer to the
>> - * array) fits into sbuf (so that mbuf will still remain
>> - * unused up to here).
>> - */
>> -mbuf = kvmalloc(array_size, GFP_KERNEL);
>> +array_buf = kvmalloc(array_size, GFP_KERNEL);
>> err = -ENOMEM;
>> -if (NULL == mbuf)
>> +if (array_buf == NULL)
>
> if (!array_buf)
> ?
>
Please ignore my previous comment, as the patch was landed. :)
--
Best regards,
Bingbu Cao
Re: [PATCH v2 0/3] fix macb phy probe failure if phy-reset is not handled
On Tue, 10 Nov 2020 07:22:09 PST (-0800), sagar.ka...@sifive.com wrote: HiFive Unleashed is having VSC8541-01 ethernet phy device and requires a specific reset sequence of 0-1-0-1 in order to use it in unmanaged mode. This series addresses a corner case where phy reset is not handled by boot stages prior to linux. Somewhat similar unreliable phy probe failure was reported and discussed here [1]. The macb driver fails to detect the ethernet phy device if the bootloader doesn't provide a proper reset sequence to the phy device or the phy itself is in some invalid state. Currently, the FSBL or u-boot-spl is resetting the phy device, and so there is no issue observed in the linux network setup. The series is based on linux-5.10-rc5. Patch 1: Add the OUI to the phy dt node to fix issue of missing mdio device Patch 2 and 3: Resetting phy needs GPIO support so add to dt and defconfig. [1] https://lkml.org/lkml/2018/11/29/154 To reproduce the issue: Using FSBL: 1. Comment out VSC8541 reset sequence in fsbl/main.c from within the freedom-u540-c000-bootloader. 2. Build and flash fsbl.bin to micro sdcard. Using u-boot: 1. Comment out VSC8541 reset sequence in board/sifive/fu540/spl.c from mainline u-boot source code. 2. Build and flash u-boot binaries to micro sdcard. Boot the board and bootlog will show network setup failure messages as: [ 1.069474] libphy: MACB_mii_bus: probed [ 1.073092] mdio_bus 1009.ethernet-: MDIO device at address 0 is missing . [ 1.979252] macb 1009.ethernet eth0: Could not attach PHY (-19) 3. Now apply the series build, and boot kernel. 4. MACB and VSC8541 driver get successfully probed and the network is set without any failure. So irrespective of whether the prior stages handle the phy reset sequence, the probing is successful in both the cases of cold boot and warm boot. Change History: === V2: -Rebased v1 on linux kernel v5.10-rc3. V1: -Ignore 4th patch as suggested and so removed it from the series. -Verified this series on 5.7-rc5. V0: Base RFC patch. Verified on 5.7-rc2 Sagar Shrikant Kadam (3): dts: phy: fix missing mdio device and probe failure of vsc8541-01 device dts: phy: add GPIO number and active state used for phy reset riscv: defconfig: enable gpio support for HiFive Unleashed arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 2 ++ arch/riscv/configs/defconfig| 2 ++ 2 files changed, 4 insertions(+) David pointed out I missed these, they're on fixes. Thanks!
Re: [PATCH] of: unittest: Statically apply overlays using fdtoverlay
Frank/Rob. On 08-01-21, 14:11, Viresh Kumar wrote: > diff --git a/drivers/of/unittest-data/Makefile > b/drivers/of/unittest-data/Makefile > index 009f4045c8e4..f17bce85f65f 100644 > --- a/drivers/of/unittest-data/Makefile > +++ b/drivers/of/unittest-data/Makefile > @@ -38,3 +38,26 @@ DTC_FLAGS_testcases += -@ > > # suppress warnings about intentional errors > DTC_FLAGS_testcases += -Wno-interrupts_property > + > +# Apply overlays statically with fdtoverlay I will update this part to mention about the dtbs we are not using in the build as they will fail (as per Frank's comment). Is there anything else you guys want me to change before I send the next version ? > +intermediate-overlay := overlay.dtb > +master := overlay_0.dtb overlay_1.dtb overlay_2.dtb \ > +overlay_3.dtb overlay_4.dtb overlay_5.dtb \ > +overlay_6.dtb overlay_7.dtb overlay_8.dtb \ > +overlay_9.dtb overlay_10.dtb overlay_11.dtb \ > +overlay_12.dtb overlay_13.dtb overlay_15.dtb \ > +overlay_gpio_01.dtb overlay_gpio_02a.dtb \ > +overlay_gpio_02b.dtb overlay_gpio_03.dtb \ > +overlay_gpio_04a.dtb overlay_gpio_04b.dtb \ > +intermediate-overlay.dtb > + > +quiet_cmd_fdtoverlay = fdtoverlay $@ > + cmd_fdtoverlay = $(objtree)/scripts/dtc/fdtoverlay -o $@ -i $^ > + > +$(obj)/intermediate-overlay.dtb: $(obj)/overlay_base.dtb $(addprefix > $(obj)/,$(intermediate-overlay)) > + $(call if_changed,fdtoverlay) > + > +$(obj)/master.dtb: $(obj)/testcases.dtb $(addprefix $(obj)/,$(master)) > + $(call if_changed,fdtoverlay) > + > +always-$(CONFIG_OF_OVERLAY) += intermediate-overlay.dtb master.dtb -- viresh
arch/arm64/kvm/hyp/nvhe/hyp-main.c:18:6: warning: no previous prototype for 'handle_trap'
Hi Andrew, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: 4e3393a969a0bdaae83263918b6824b2d08c3996 KVM: arm64: nVHE: Switch to hyp context for EL2 date: 4 months ago config: arm64-randconfig-r005-20210113 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e3393a969a0bdaae83263918b6824b2d08c3996 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 4e3393a969a0bdaae83263918b6824b2d08c3996 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arch/arm64/kvm/hyp/nvhe/hyp-main.c:18:6: warning: no previous prototype for >> 'handle_trap' [-Wmissing-prototypes] 18 | void handle_trap(struct kvm_cpu_context *host_ctxt) | ^~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for NVMEM_IMX_OCOTP Depends on NVMEM && (ARCH_MXC || COMPILE_TEST && HAS_IOMEM Selected by - ARM_IMX6Q_CPUFREQ && CPU_FREQ && (ARM || ARM64 && ARCH_MXC && REGULATOR_ANATOP vim +/handle_trap +18 arch/arm64/kvm/hyp/nvhe/hyp-main.c 14 15 typedef unsigned long (*hypcall_fn_t) 16 (unsigned long, unsigned long, unsigned long); 17 > 18 void handle_trap(struct kvm_cpu_context *host_ctxt) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: riscv+KASAN does not boot
On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab wrote: On Dez 25 2020, Dmitry Vyukov wrote: > qemu-system-riscv64 \ > -machine virt -bios default -smp 1 -m 2G \ > -device virtio-blk-device,drive=hd0 \ > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > -kernel arch/riscv/boot/Image \ > -nographic \ > -device virtio-rng-device,rng=rng0 -object > rng-random,filename=/dev/urandom,id=rng0 \ > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > virtio-net-device,netdev=net0 \ > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > panic_on_warn=1 panic=86400" Do you get more output with earlycon=sbi? Hi Andreas, For defconfig+kvm_guest.config+ scripts/config -e KASAN -e KASAN_INLINE it actually gave me more output: OpenSBI v0.7 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : QEMU Virt Machine Platform HART Features : RV64ACDFIMSU Current Hart : 0 Firmware Base : 0x8000 Firmware Size : 132 KB Runtime SBI Version: 0.2 MIDELEG : 0x0222 MEDELEG : 0xb109 PMP0: 0x8000-0x8003 (A) PMP1: 0x-0x (A,R,W,X) [0.00] Linux version 5.10.0-01370-g71c5f03154ac (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 SMP Fri Dec 25 18:10:12 CET 2020 [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 [0.00] earlycon: sbi0 at I/O port 0x0 (options '') [0.00] printk: bootconsole [sbi0] enabled [0.00] efi: UEFI not found. [0.00] Zone ranges: [0.00] DMA32[mem 0x8020-0x] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8020-0x] [0.00] Initmem setup node 0 [mem 0x8020-0x] [0.00] SBI specification v0.2 detected [0.00] SBI implementation ID=0x1 Version=0x7 [0.00] SBI v0.2 TIME extension detected [0.00] SBI v0.2 IPI extension detected [0.00] SBI v0.2 RFENCE extension detected [0.00] software IO TLB: mapped [mem 0xfa3f9000-0xfe3f9000] (64MB) [0.00] Unable to handle kernel paging request at virtual address dfc81004 [0.00] Oops [#1] [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-01370-g71c5f03154ac #17 [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : ffe001603ea0 [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : dfc81004 [0.00] t1 : ffe000e0a838 t2 : s0 : ffe001603f50 [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : [0.00] a2 : 0ffc a3 : dfc82000 a4 : [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : 0900 [0.00] s2 : dfc82000 s3 : dfc8 s4 : 0001 [0.00] s5 : ffe0016e5108 s6 : f000 s7 : dfc81004 [0.00] s8 : 0080 s9 : s10: ffe07a119000 [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : 0001 [0.00] t5 : ffc4001c150a t6 : ffe001603be8 [0.00] status: 0100 badaddr: dfc81004 cause: 000f [0.00] random: get_random_bytes called from oops_exit+0x30/0x58 with crng_init=0 [0.00] ---[ end trace ]--- [0.00] Kernel panic - not syncing: Fatal exception [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- But I first tried with a the kernel image I had in the dir, I think it was this config (no KASAN): https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt and earlycon=sbi did not change anything (no output after OpenSBI). So potentially there are 2 different problems. Thanks for reporting this. Looks like I'd forgotten to add a kasan config to my tests. There's one in there now, and it's passing as of the fix that Nylon posted.
Re: [PATCH 1/1] riscv: Fix KASAN memory mapping.
On Tue, 12 Jan 2021 18:24:10 PST (-0800), nyl...@andestech.com wrote:
From: Nick Hu
Use virtual address instead of physical address when translating
the address to shadow memory by kasan_mem_to_shadow().
Signed-off-by: Nick Hu
Signed-off-by: Nylon Chen
---
arch/riscv/mm/kasan_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 12ddd1f6bf70..a8a2ffd9114a 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -93,8 +93,8 @@ void __init kasan_init(void)
VMALLOC_END));
for_each_mem_range(i, &_start, &_end) {
- void *start = (void *)_start;
- void *end = (void *)_end;
+ void *start = (void *)__va(_start);
+ void *end = (void *)__va(_end);
if (start >= end)
break;
Thanks, this is on fixes.
Re: Toolchain-dependent config options
On Thu, Jan 14, 2021 at 7:21 AM Josh Poimboeuf wrote: > > Hi Masahiro, > > If I copy a config with CONFIG_GCC_PLUGINS to another system which > doesn't have the gcc-plugin-devel package, it gets silently disabled by > "make olddefconfig". > > I've seen multiple cases lately where this is causing confusion. I > suspect the problem is getting worse with recent added support for a > variety of toolchains and toolchain-dependent features. > > Would it be possible to have an error (or at least a warning) in this > case? > > For example, a "depends-error" which triggers an error if its failure > would disable a feature? > > -- > Josh > We disable any feature that is unsupported by the compiler in use. Conventionally, we did that in the top Makefile by using $(call cc-option, ) macro or by running some scripts. Recently, we are moving such compiler tests to the Kconfig stage. Anyway, we disable unsupported features so any combination of CONFIG options builds successfully. This will ease randconfg and allmodconfig tests. A lot of people and CI systems are running allmodconfig tests for various architectures and toolchains. Introducing the build breakage is annoying. -- Best Regards Masahiro Yamada
Re: [PATCH] bcache: consider the fragmentation when update the writeback rate
[Share the google doc here to avoid SPAM detection] Here is the new testing result with multiple threads fio testing: https://docs.google.com/document/d/1AmbIEa_2MhB9bqhC3rfga9tp7n9YX9PLn0jSUxscVW0/edit?usp=sharing On Fri, Jan 8, 2021 at 4:47 PM Dongdong Tao wrote: > > Yeap, I will scale the testing for multiple threads with larger IO > depth, thanks for the suggestion! > > On Fri, Jan 8, 2021 at 4:40 PM Coly Li wrote: > > > > On 1/8/21 4:30 PM, Dongdong Tao wrote: > > > Hi Coly, > > > > > > They are captured with the same time length, the meaning of the > > > timestamp and the time unit on the x-axis are different. > > > (Sorry, I should have clarified this right after the chart) > > > > > > For the latency chart: > > > The timestamp is the relative time since the beginning of the > > > benchmark, so the start timestamp is 0 and the unit is based on > > > millisecond > > > > > > For the dirty data and cache available percent chart: > > > The timestamp is the UNIX timestamp, the time unit is based on second, > > > I capture the stats every 5 seconds with the below script: > > > --- > > > #!/bin/sh > > > while true; do echo "`date +%s`, `cat > > > /sys/block/bcache0/bcache/dirty_data`, `cat > > > /sys/block/bcache0/bcache/cache/cache_available_percent`, `cat > > > /sys/block/bcache0/bcache/writeback_rate`" >> $1; sleep 5; done; > > > --- > > > > > > Unfortunately, I can't easily make them using the same timestamp, but > > > I guess I can try to convert the UNIX timestamp to the relative time > > > like the first one. > > > But If we ignore the value of the X-axis, we can still roughly > > > compare them by using the length of the X-axis since they have the > > > same time length, > > > and we can see that the Master's write start hitting the backing > > > device when the cache_available_percent dropped to around 30. > > > > Copied, thanks for the explanation. The chart for single thread with io > > depth 1 is convinced IMHO :-) > > > > One more question, the benchmark is about a single I/O thread with io > > depth 1, which is not typical condition for real workload. Do you have > > plan to test the latency and IOPS for multiple threads with larger I/O > > depth ? > > > > > > Thanks. > > > > > > Coly Li > > > > > > > > > > On Fri, Jan 8, 2021 at 12:06 PM Coly Li wrote: > > >> > > >> On 1/7/21 10:55 PM, Dongdong Tao wrote: > > >>> Hi Coly, > > >>> > > >>> > > >>> Thanks for the reminder, I understand that the rate is only a hint of > > >>> the throughput, it’s a value to calculate the sleep time between each > > >>> round of keys writeback, the higher the rate, the shorter the sleep > > >>> time, most of the time this means the more dirty keys it can writeback > > >>> in a certain amount of time before the hard disk running out of speed. > > >>> > > >>> > > >>> Here is the testing data that run on a 400GB NVME + 1TB NVME HDD > > >>> > > >> > > >> Hi Dongdong, > > >> > > >> Nice charts :-) > > >> > > >>> Steps: > > >>> > > >>> 1. > > >>> > > >>> make-bcache -B -C --writeback > > >>> > > >>> 2. > > >>> > > >>> sudo fio --name=random-writers --filename=/dev/bcache0 > > >>> --ioengine=libaio --iodepth=1 --rw=randrw --blocksize=64k,8k > > >>> --direct=1 --numjobs=1 --write_lat_log=mix --log_avg_msec=10 > > The fio benchmark commands ran for about 20 hours. > > >>> > > >> > > >> The time lengths of first 3 charts are 7.000e+7, rested are 1.60930e+9. > > >> I guess the time length of the I/O latency chart is 1/100 of the rested. > > >> > > >> Can you also post the latency charts for 1.60930e+9 seconds? Then I can > > >> compare the latency with dirty data and available cache charts. > > >> > > >> > > >> Thanks. > > >> > > >> > > >> Coly Li > > >> > > >> > > >> > > >> > > >> > > >>> > > >>> Let’s have a look at the write latency first: > > >>> > > >>> Master: > > >>> > > >>> > > >>> > > >>> Master+the patch: > > >>> > > >>> Combine them together: > > >>> > > >>> Again, the latency (y-axis) is based on nano-second, x-axis is the > > >>> timestamp based on milli-second, as we can see the master latency is > > >>> obviously much higher than the one with my patch when the master bcache > > >>> hit the cutoff writeback sync, the master isn’t going to get out of this > > >>> cutoff writeback sync situation, This graph showed it already stuck at > > >>> the cutoff writeback sync for about 4 hours before I finish the testing, > > >>> it may still needs to stuck for days before it can get out this > > >>> situation itself. > > >>> > > >>> > > >>> Note that there are 1 million points for each , red represents master, > > >>> green represents mater+my patch. Most of them are overlapped with each > > >>> other, so it may look like this graph has more red points then green > > >>> after it hitting the cutoff, but simply it’s because the latency has > > >>> scaled to a bigger range which represents the HDD latency. > > >>> > > >>> > > >>> > > >>> Let’s also have a look at the bcache’s cache
Re: [PATCH v2] pinctrl: sprd: Simplify bool comparison
On Wed, Jan 13, 2021 at 11:43 AM Yang Li wrote:
>
> Fix the following coccicheck warning:
> ./drivers/pinctrl/sprd/pinctrl-sprd.c:690:8-23: WARNING: Comparison to
> bool
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
You should keep other guy's reviewed-by or acked-by tag for the
following version if no other big changes. So again
Reviewed-by: Baolin Wang
> ---
> Changes in v2:
> - make "pinctrl: sprd:" as subject prefix
>
> drivers/pinctrl/sprd/pinctrl-sprd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c
> b/drivers/pinctrl/sprd/pinctrl-sprd.c
> index 08dc193..dca7a50 100644
> --- a/drivers/pinctrl/sprd/pinctrl-sprd.c
> +++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
> @@ -687,7 +687,7 @@ static int sprd_pinconf_set(struct pinctrl_dev *pctldev,
> unsigned int pin_id,
> shift = INPUT_SCHMITT_SHIFT;
> break;
> case PIN_CONFIG_BIAS_PULL_UP:
> - if (is_sleep_config == true) {
> + if (is_sleep_config) {
> val |= SLEEP_PULL_UP;
> mask = SLEEP_PULL_UP_MASK;
> shift = SLEEP_PULL_UP_SHIFT;
> --
> 1.8.3.1
>
--
Baolin Wang
Re: [PATCH] perf tools: Resolve symbols against debug file first
Hi both of Jiri,
On Wed, Jan 13, 2021 at 8:43 PM Jiri Slaby wrote:
>
> On 13. 01. 21, 11:46, Jiri Olsa wrote:
> > On Wed, Jan 13, 2021 at 09:01:28AM +0100, Jiri Slaby wrote:
> >> With LTO, there are symbols like these:
> >> /usr/lib/debug/usr/lib64/libantlr4-runtime.so.4.8-4.8-1.4.x86_64.debug
> >> 10305: 00955fa4 0 NOTYPE LOCAL DEFAULT 29
> >> Predicate.cpp.2bc410e7
> >>
> >> This comes from a runtime/debug split done by the standard way:
> >> objcopy --only-keep-debug $runtime $debug
> >> objcopy --add-gnu-debuglink=$debugfn -R .comment -R .GCC.command.line
> >> --strip-all $runtime
> >>
> >> perf currently cannot resolve such symbols (relicts of LTO), as section
> >> 29 exists only in the debug file (29 is .debug_info). And perf resolves
> >> symbols only against runtime file. This results in all symbols from such
> >> a library being unresolved:
> >> 0.38% main2libantlr4-runtime.so.4.8 [.] 0x000671e0
> >>
> >> So try resolving against the debug file first. And only if it fails (the
> >> section has NOBITS set), try runtime file. We can do this, as "objcopy
> >> --only-keep-debug" per documentation preserves all sections, but clears
> >> data of some of them (the runtime ones) and marks them as NOBITS.
> >>
> >> The correct result is now:
> >> 0.38% main2libantlr4-runtime.so.4.8 [.]
> >> antlr4::IntStream::~IntStream
> >>
> >> Note that these LTO symbols are properly skipped anyway as they belong
> >> neither to *text* nor to *data* (is_label && !elf_sec__filter(,
> >> secstrs) is true).
> >>
> >> Signed-off-by: Jiri Slaby
> >> Cc: Peter Zijlstra
> >> Cc: Ingo Molnar
> >> Cc: Arnaldo Carvalho de Melo
> >> Cc: Mark Rutland
> >> Cc: Alexander Shishkin
> >> Cc: Jiri Olsa
> >> Cc: Namhyung Kim
> >> ---
> >> tools/perf/util/symbol-elf.c | 10 +-
> >> 1 file changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> >> index f3577f7d72fe..a31b716fa61c 100644
> >> --- a/tools/perf/util/symbol-elf.c
> >> +++ b/tools/perf/util/symbol-elf.c
> >> @@ -1226,12 +1226,20 @@ int dso__load_sym(struct dso *dso, struct map
> >> *map, struct symsrc *syms_ss,
> >> if (sym.st_shndx == SHN_ABS)
> >> continue;
> >>
> >> -sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> >> +sec = elf_getscn(syms_ss->elf, sym.st_shndx);
> >> if (!sec)
> >> goto out_elf_end;
> >
> > we iterate symbols from syms_ss, so the fix seems to be correct
> > to call elf_getscn on syms_ss, not on runtime_ss as we do now
> >
> > I'd think this worked only when runtime_ss == syms_ss
>
> No, because the headers are copied 1:1 from runtime_ss to syms_ss. And
> runtime_ss is then stripped, so only .debug* sections are removed there.
> (And syms_ss's are set as NOBITS.)
>
> We iterated .debug* sections in syms_ss and used runtime_ss section
> _headers_ only to adjust symbols (sometimes). That worked.
It seems PPC has an opd section only in the runtime_ss and that's why
we use it for section headers.
>
> >> gelf_getshdr(sec, );
> >>
> >> +if (shdr.sh_type == SHT_NOBITS) {
> >> +sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> >> +if (!sec)
> >> +goto out_elf_end;
> >> +
> >> +gelf_getshdr(sec, );
> >> +}
> >
> > is that fallback necessary? the symbol is from syms_ss
>
> Provided the above, we don't need the section data here, only headers,
> so the NOBITS test is superfluous and the fallback shouldn't be needed.
> Let me test it.
We need to talk to PPC folks like I said. Or maybe we can change the
default ss depending on the arch.
Thanks,
Namhyung
Re: [PATCH v2 1/1] v4l: ioctl: Fix memory leak in video_usercopy
Sakari,
On 12/21/20 4:11 AM, Sakari Ailus wrote:
> When an IOCTL with argument size larger than 128 that also used array
> arguments were handled, two memory allocations were made but alas, only
> the latter one of them was released. This happened because there was only
> a single local variable to hold such a temporary allocation.
>
> Fix this by adding separate variables to hold the pointers to the
> temporary allocations.
>
> Reported-by: Arnd Bergmann
> Reported-by: syzbot+1115e79c8df6472c6...@syzkaller.appspotmail.com
> Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sakari Ailus
> Reviewed-by: Laurent Pinchart
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 32
> 1 file changed, 14 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 3198abdd538c..9906b41004e9 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -3283,7 +3283,7 @@ video_usercopy(struct file *file, unsigned int
> orig_cmd, unsigned long arg,
> v4l2_kioctl func)
> {
> charsbuf[128];
> - void*mbuf = NULL;
> + void*mbuf = NULL, *array_buf = NULL;
> void*parg = (void *)arg;
> longerr = -EINVAL;
> boolhas_array_args;
> @@ -3318,27 +3318,21 @@ video_usercopy(struct file *file, unsigned int
> orig_cmd, unsigned long arg,
> has_array_args = err;
>
> if (has_array_args) {
> - /*
> - * When adding new types of array args, make sure that the
> - * parent argument to ioctl (which contains the pointer to the
> - * array) fits into sbuf (so that mbuf will still remain
> - * unused up to here).
> - */
> - mbuf = kvmalloc(array_size, GFP_KERNEL);
> + array_buf = kvmalloc(array_size, GFP_KERNEL);
> err = -ENOMEM;
> - if (NULL == mbuf)
> + if (array_buf == NULL)
if (!array_buf)
?
> goto out_array_args;
> err = -EFAULT;
> if (in_compat_syscall())
> - err = v4l2_compat_get_array_args(file, mbuf, user_ptr,
> - array_size, orig_cmd,
> - parg);
> + err = v4l2_compat_get_array_args(file, array_buf,
> + user_ptr, array_size,
> + orig_cmd, parg);
> else
> - err = copy_from_user(mbuf, user_ptr, array_size) ?
> + err = copy_from_user(array_buf, user_ptr, array_size) ?
> -EFAULT : 0;
> if (err)
> goto out_array_args;
> - *kernel_ptr = mbuf;
> + *kernel_ptr = array_buf;
> }
>
> /* Handles IOCTL */
> @@ -3360,12 +3354,13 @@ video_usercopy(struct file *file, unsigned int
> orig_cmd, unsigned long arg,
> if (in_compat_syscall()) {
> int put_err;
>
> - put_err = v4l2_compat_put_array_args(file, user_ptr,
> mbuf,
> - array_size,
> orig_cmd,
> - parg);
> + put_err = v4l2_compat_put_array_args(file, user_ptr,
> + array_buf,
> + array_size,
> + orig_cmd, parg);
> if (put_err)
> err = put_err;
> - } else if (copy_to_user(user_ptr, mbuf, array_size)) {
> + } else if (copy_to_user(user_ptr, array_buf, array_size)) {
> err = -EFAULT;
> }
> goto out_array_args;
> @@ -3381,6 +3376,7 @@ video_usercopy(struct file *file, unsigned int
> orig_cmd, unsigned long arg,
> if (video_put_user((void __user *)arg, parg, cmd, orig_cmd))
> err = -EFAULT;
> out:
> + kvfree(array_buf);
> kvfree(mbuf);
> return err;
> }
>
--
Best regards,
Bingbu Cao
Re: [PATCH] bio: limit bio max size.
>On 2021/01/14 12:53, Ming Lei wrote: >> On Wed, Jan 13, 2021 at 12:02:44PM +, Damien Le Moal wrote: >>> On 2021/01/13 20:48, Ming Lei wrote: On Wed, Jan 13, 2021 at 11:16:11AM +, Damien Le Moal wrote: > On 2021/01/13 19:25, Ming Lei wrote: >> On Wed, Jan 13, 2021 at 09:28:02AM +, Damien Le Moal wrote: >>> On 2021/01/13 18:19, Ming Lei wrote: On Wed, Jan 13, 2021 at 12:09 PM Changheun Lee wrote: > >> On 2021/01/12 21:14, Changheun Lee wrote: On 2021/01/12 17:52, Changheun Lee wrote: > From: "Changheun Lee" > > bio size can grow up to 4GB when muli-page bvec is enabled. > but sometimes it would lead to inefficient behaviors. > in case of large chunk direct I/O, - 64MB chunk read in user > space - > all pages for 64MB would be merged to a bio structure if memory > address is > continued phsycally. it makes some delay to submit until merge > complete. > bio max size should be limited as a proper size. But merging physically contiguous pages into the same bvec + later automatic bio split on submit should give you better throughput for large IOs compared to having to issue a bio chain of smaller BIOs that are arbitrarily sized and will likely need splitting anyway (because of DMA boundaries etc). Do you have a specific case where you see higher performance with this patch applied ? On Intel, BIO_MAX_SIZE would be 1MB... That is arbitrary and too small considering that many hardware can execute larger IOs than that. >>> >>> When I tested 32MB chunk read with O_DIRECT in android, all pages >>> of 32MB >>> is merged into a bio structure. >>> And elapsed time to merge complete was about 2ms. >>> It means first bio-submit is after 2ms. >>> If bio size is limited with 1MB with this patch, first bio-submit >>> is about >>> 100us by bio_full operation. >> >> bio_submit() will split the large BIO case into multiple requests >> while the >> small BIO case will likely result one or two requests only. That >> likely explain >> the time difference here. However, for the large case, the 2ms will >> issue ALL >> requests needed for processing the entire 32MB user IO while the 1MB >> bio case >> will need 32 different bio_submit() calls. So what is the actual >> total latency >> difference for the entire 32MB user IO ? That is I think what needs >> to be >> compared here. >> >> Also, what is your device max_sectors_kb and max queue depth ? >> > > 32MB total latency is about 19ms including merge time without this > patch. > But with this patch, total latency is about 17ms including merge time > too. 19ms looks too big just for preparing one 32MB sized bio, which isn't supposed to take so long. Can you investigate where the 19ms is taken just for preparing one 32MB sized bio? >>> >>> Changheun mentioned that the device side IO latency is 16.7ms out of >>> the 19ms >>> total. So the BIO handling, submission+completion takes about 2.3ms, and >>> Changheun points above to 2ms for the submission part. >> >> OK, looks I misunderstood the data. >> >>> It might be iov_iter_get_pages() for handling page fault. If yes, one suggestion is to enable THP(Transparent HugePage Support) in your application. >>> >>> But if that was due to page faults, the same large-ish time would be >>> taken for >>> the preparing the size-limited BIOs too, no ? No matter how the BIOs >>> are diced, >>> all 32MB of pages of the user IO are referenced... >> >> If bio size is reduced to 1MB, just 256 pages need to be faulted before >> submitting this >> bio, instead of 256*32 pages, that is why the following words are >> mentioned: >> >> It means first bio-submit is after 2ms. >> If bio size is limited with 1MB with this patch, first bio-submit is >> about >> 100us by bio_full operation. > > Yes, but eventually, all pages for the 32MB IO will be faulted in, just > not in > one go. Overall number of page faults is likely the same as with the > large BIO > preparation. So I think we are back to my previous point, that is, > reducing the > device idle time by starting a BIO more quickly, even a small one, leads > to > overlap between CPU time needed for the next BIO
Re: [PATCH v3] x86/sgx: Synchronize encl->srcu in sgx_encl_release().
On Mon, 11 Jan 2021 18:08:10 -0600, Jarkko Sakkinen
wrote:
On Tue, Jan 05, 2021 at 03:57:49PM +0100, Borislav Petkov wrote:
On Wed, Dec 16, 2020 at 03:49:20PM +0200, Jarkko Sakkinen wrote:
> Add synchronize_srcu_expedited() to sgx_encl_release() to catch a
grace
> period initiated by sgx_mmu_notifier_release().
>
> A trivial example of a failing sequence with tasks A and B:
>
> 1. A: -> sgx_release()
> 2. B: -> sgx_mmu_notifier_release()
> 3. B: -> list_del_rcu()
> 3. A: -> sgx_encl_release()
> 4. A: -> cleanup_srcu_struct()
>
> The loop in sgx_release() observes an empty list because B has
removed its
> entry in the middle, and calls cleanup_srcu_struct() before B has a
chance
> to calls synchronize_srcu().
Leading to what? NULL ptr?
https://lkml.kernel.org/r/x9e2jowz1hfxv...@google.com
already suggested that you should explain the bug better and add the
splat but I'm still missing that explanation.
OK, I'll try to explain it how I understand the issue.
Consider this loop in the VFS release hook (sgx_release):
/*
* Drain the remaining mm_list entries. At this point the list contains
* entries for processes, which have closed the enclave file but have
* not exited yet. The processes, which have exited, are gone from the
* list by sgx_mmu_notifier_release().
*/
for ( ; ; ) {
spin_lock(>mm_lock);
if (list_empty(>mm_list)) {
encl_mm = NULL;
} else {
encl_mm = list_first_entry(>mm_list,
struct sgx_encl_mm, list);
list_del_rcu(_mm->list);
}
spin_unlock(>mm_lock);
/* The enclave is no longer mapped by any mm. */
if (!encl_mm)
break;
synchronize_srcu(>srcu);
mmu_notifier_unregister(_mm->mmu_notifier, encl_mm->mm);
kfree(encl_mm);
}
At this point all processes have closed the enclave file, but that
doesn't
mean that they all have exited yet.
Now, let's imagine that there is exactly one entry in the encl->mm_list.
and sgx_release() execution gets scheduled right after returning from
synchronize_srcu().
With some bad luck, some process comes and removes that last entry befoe
sgx_release() acquires mm_lock. The loop in sgx_release() just leaves
/* The enclave is no longer mapped by any mm. */
if (!encl_mm)
break;
No synchronize_srcu().
After writing this, I think that the placement for synchronize_srcu()
in this patch is not best possible. It should be rather that the
above loop would also call synchronize_srcu() when leaving.
I.e. the code change would result:
for ( ; ; ) {
spin_lock(>mm_lock);
if (list_empty(>mm_list)) {
encl_mm = NULL;
} else {
encl_mm = list_first_entry(>mm_list,
struct sgx_encl_mm, list);
list_del_rcu(_mm->list);
}
spin_unlock(>mm_lock);
/*
* synchronize_srcu() is mandatory *even* when the list
was
* empty, in order make sure that grace periods stays in
* sync even when another task took away the last entry
* (i.e. exiting process when it deletes its mm_list).
*/
synchronize_srcu(>srcu);
/* The enclave is no longer mapped by any mm. */
if (!encl_mm)
break;
mmu_notifier_unregister(_mm->mmu_notifier, encl_mm->mm);
kfree(encl_mm);
}
What do you think? Does this start to make more sense now?
I don't have logs for this but the bug can be also reasoned.
/Jarkko
I did this experiment just now and find it runs much much slower than both
original code and code with synchronize_srcu_expedited fix in this patch.
Haitao
Re: madvise(MADV_REMOVE) deadlocks on shmem THP
On Thu, 14 Jan 2021, Sergey Senozhatsky wrote:
> Hi,
>
> We are running into lockups during the memory pressure tests on our
> boards, which essentially NMI panic them. In short the test case is
>
> - THP shmem
> echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled
>
> - And a user-space process doing madvise(MADV_HUGEPAGE) on new mappings,
> and madvise(MADV_REMOVE) when it wants to remove the page range
>
> The problem boils down to the reverse locking chain:
> kswapd does
>
> lock_page(page) -> down_read(page->mapping->i_mmap_rwsem)
>
> madvise() process does
>
> down_write(page->mapping->i_mmap_rwsem) -> lock_page(page)
>
>
>
> CPU0 CPU1
>
> kswapd vfs_fallocate()
> shrink_node() shmem_fallocate()
> shrink_active_list()
> unmap_mapping_range()
>page_referenced() << lock page:PG_locked >>
> unmap_mapping_pages() << down_write(mapping->i_mmap_rwsem) >>
> rmap_walk_file()
> zap_page_range_single()
> down_read(mapping->i_mmap_rwsem) << W-locked on CPU1>>
> unmap_page_range()
> rwsem_down_read_failed()
> __split_huge_pmd()
>__rwsem_down_read_failed_common()
> __lock_page() << PG_locked on CPU0 >>
> schedule()
> wait_on_page_bit_common()
>
> io_schedule()
Very interesting, Sergey: many thanks for this report.
There is no doubt that kswapd is right in its lock ordering:
__split_huge_pmd() is in the wrong to be attempting lock_page().
Which used not to be done, but was added in 5.8's c444eb564fb1 ("mm:
thp: make the THP mapcount atomic against __split_huge_pmd_locked()").
Which explains why this deadlock was not seen years ago: that
surprised me at first, since the case you show to reproduce it is good,
but I'd expect more common ways in which that deadlock could show up.
And your report is remarkably timely too: I have two other reasons
for looking at that change at the moment (I'm currently catching up
with recent discussion of page_count versus mapcount when deciding
COW page reuse).
I won't say more tonight, but should have more to add tomorrow.
Hugh
Re: [rcu:rcu/next] BUILD SUCCESS WITH WARNING f81f6edb74f27c5c8917d20a2bc128aca39aae11
t; powerpc tqm8560_defconfig > > > sh ecovec24_defconfig > > > c6xevmc6457_defconfig > > > armmvebu_v7_defconfig > > > mips pistachio_defconfig > > > m68k multi_defconfig > > > s390 zfcpdump_defconfig > > > xtensasmp_lx200_defconfig > > > h8300h8300h-sim_defconfig > > > arm multi_v4t_defconfig > > > arm davinci_all_defconfig > > > sh r7780mp_defconfig > > > armkeystone_defconfig > > > ia64zx1_defconfig > > > mips maltaaprp_defconfig > > > sh se7724_defconfig > > > sh urquell_defconfig > > > sparcalldefconfig > > > armmulti_v5_defconfig > > > powerpc pmac32_defconfig > > > powerpc ksi8560_defconfig > > > powerpcamigaone_defconfig > > > arc haps_hs_smp_defconfig > > > cskydefconfig > > > umkunit_defconfig > > > powerpc mpc832x_rdb_defconfig > > > powerpc mgcoge_defconfig > > > ia64generic_defconfig > > > powerpc bamboo_defconfig > > > arm pxa255-idp_defconfig > > > sh se7705_defconfig > > > parisc defconfig > > > m68km5407c3_defconfig > > > m68k atari_defconfig > > > powerpc mpc832x_mds_defconfig > > > powerpcfsp2_defconfig > > > m68k m5275evb_defconfig > > > powerpc ppc44x_defconfig > > > armqcom_defconfig > > > shecovec24-romimage_defconfig > > > arm tango4_defconfig > > > mips ath25_defconfig > > > sh sh2007_defconfig > > > arm socfpga_defconfig > > > m68k m5249evb_defconfig > > > mips decstation_64_defconfig > > > ia64 allmodconfig > > > ia64defconfig > > > ia64 allyesconfig > > > m68k allmodconfig > > > m68kdefconfig > > > m68k allyesconfig > > > nios2 defconfig > > > arc allyesconfig > > > nds32 allnoconfig > > > c6x allyesconfig > > > nds32 defconfig > > > nios2allyesconfig > > > alpha defconfig > > > alpha allyesconfig > > > xtensa allyesconfig > > > h8300allyesconfig > > > arc defconfig > > > sh allmodconfig > > > s390 allyesconfig > > > parisc allyesconfig > > > s390defconfig > > > i386 allyesconfig > > > sparcallyesconfig > > > sparc defconfig > > > i386 tinyconfig > > > i386defconfig > > > mips allyesconfig > > > mips allmodconfig > > > powerpc allyesconfig > > > powerpc allmodconfig > > > powerpc allnoconfig > > > x86_64 randconfig-a006-20210113 > > > x86_64 randconfig-a004-20210113 > > > x86_64 randconfig-a001-20210113 > > > x86_64 randconfig-a005-20210113 > > > x86_64 randconfig-a003-20210113 > > &g
