Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
On Mon, Dec 12, 2016 at 12:43:11PM -0600, Rob Herring wrote: > On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote: > > Hi Simon, > > > > On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman > > wrote: > > > In the case of Renesas R-Car hardware we know that there are generations > > > of > > > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the > > > > it's > > > > > relationship between IP blocks might be. For example, I believe that > > > r8a7779 is older than r8a7778 but that doesn't imply that the latter is a > > > descendant of the former or vice versa. > > > > > > We can, however, by examining the documentation and behaviour of the > > > hardware at run-time observe that the current driver implementation > > > appears > > > to be compatible with the IP blocks on SoCs within a given generation. > > > > > > For the above reasons and convenience when enabling new SoCs a > > > per-generation fallback compatibility string scheme being adopted for > > > drivers for Renesas SoCs. > > > > > > Signed-off-by: Simon Horman > > > --- > > > .../interrupt-controller/renesas,intc-irqpin.txt | 44 > > > -- > > > drivers/irqchip/irq-renesas-intc-irqpin.c | 2 + > > > 2 files changed, 26 insertions(+), 20 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt > > > > > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt > > > index 772c550d3b4b..e5a5251be9f5 100644 > > > --- > > > a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt > > > +++ > > > b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt > > > @@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller > > > > > > Required properties: > > > > > > -- compatible: has to be "renesas,intc-irqpin-", > > > "renesas,intc-irqpin" > > > - as fallback. > > > - Examples with soctypes are: > > > +- compatible: > > > - "renesas,intc-irqpin-r8a7740" (R-Mobile A1) > > > - "renesas,intc-irqpin-r8a7778" (R-Car M1A) > > > - "renesas,intc-irqpin-r8a7779" (R-Car H1) > > > - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5) > > > +- "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible > > > device) > > > > Does it make sense to add a new family-specific compatible value to a driver > > that's unlikely to receive more users in the future? More recent SoCs use > > renesas,irqc. > > If that's the case, then no. Please don't go crazy with your generic > strings. I don't mind them, but I don't know that I'd call it best > practice. Understood. I do not see any new users of this driver on the horizon and given the above I withdraw this patch.
Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs
On Wed, Dec 14, 2016 at 01:04:04PM +0800, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote: > > On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote: > > > The driver put a constant buffer of all zeros on the stack and > > > pointed a scatterlist entry at it in two places. This doesn't work > > > with virtual stacks. Use ZERO_PAGE instead. > > > > Wait a second... > > > > > - sg_set_buf(&sg_out[1], pad, sizeof pad); > > > + sg_set_buf(&sg_out[1], empty_zero_page, 16); > > > > My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what > > exactly is the code trying to do? The old code makes no sense. It's > > setting the *output* buffer to zeroed padding. > > It's decrypting so I presume it just needs to the extra space for > the padding and the result will be thrown away. > It looks like the data is zero-padded to a 16-byte AES block boundary before being encrypted with CBC, so the encrypted data may be longer than the original data. (I don't know why it doesn't use CTS mode instead, which would make the lengths the same.) Since the crypto API can do in-place operations, when *encrypting* I suggest copying the decrypted data to the output buffer, padding it with 0's, and encrypting it in-place. This eliminates the need for the stack buffer. But when *decrypting* there will be up to 15 extra throwaway bytes of output produced by the decryption. There must be space made for these, and since it's output it can't be empty_zero_page. I guess either check whether space can be made for it in-place, or allocate a temporary buffer... Eric
Re: linux-next: build warning after merge of the tip tree
Hi Ingo, On Wed, 14 Dec 2016 08:24:11 +0100 Ingo Molnar wrote: > > FYI, f4f61d2cc6d8 is not in the -tip tree, so it cannot possibly have > introduced > this warning. Yeah, I know, but the warning only seemed to happen after merging the tip tree. I would have expected it to appear much earlier like when I merged the ubifs tree. I figured that out, but forgot to mention it, sorry. Actually I just checked and it did turn up then, but my heuristics did not point it out :-( -- Cheers, Stephen Rothwell
[PATCH v9 0/4] Add Mediatek JPEG Decoder
This series of patches provide a v4l2 driver to control Mediatek JPEG decoder for decoding JPEG image and Motion JPEG bitstream. changes since v8: - Fix state error in first bit stream when capture buffer has been stream on. This will trigger device run inadvertently. changes since v7: - Update MAINTAINERS changes since v6: - fix kbuild test fail - Add patch for MAINTAINERS changes since v5: - remove redundant name from struct mtk_jpeg_fmt - Set state of all buffers to VB2_BUF_STATE_QUEUED if fail in start streaming - Remove VB2_USERPTR - Add check for buffer index changes since v4: - Change file name of binding documentation - Revise DT binding documentation - Revise compatible string changes since v3: - Revise DT binding documentation - Revise compatible string changes since v2: - Revise DT binding documentation changes since v1: - Rebase for v4.9-rc1. - Update Compliance test version and result - Remove redundant path in Makefile - Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP - Fix warnings from patch check and smatch check * Dependency The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: CCF "Add clock support for Mediatek MT2701"[1] iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2] [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html [2] https://patchwork.kernel.org/patch/9164013/ * Compliance test v4l2-compliance SHA : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a Driver Info: Driver name : mtk-jpeg decode Card type : mtk-jpeg decoder Bus info : platform:15004000.jpegdec Driver version: 4.9.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Compliance test for device /dev/video3 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK test Scaling: OK Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Total: 43, Succeeded: 43, Failed: 0, Warnings: 0 Rick Chang (4): dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder vcodec: mediatek: Add Mediatek JPEG Decoder Driver arm: dts: mt2701: Add node for Mediatek JPEG Decoder vcodec: mediatek: Add Maintainers entr
[PATCH v9 1/4] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
Acked-by: Rob Herring
---
.../bindings/media/mediatek-jpeg-decoder.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
new file mode 100644
index 000..3813947
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -0,0 +1,37 @@
+* Mediatek JPEG Decoder
+
+Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs
+
+Required properties:
+- compatible : must be one of the following string:
+ "mediatek,mt8173-jpgdec"
+ "mediatek,mt2701-jpgdec"
+- reg : physical base address of the jpeg decoder registers and length of
+ memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+ Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgdec-smi" and "jpgdec".
+- power-domains: a phandle to the power domain, see
+ Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+ Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details.
+- iommus: should point to the respective IOMMU block with master port as
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ for details.
+
+Example:
+ jpegdec: jpegdec@15004000 {
+ compatible = "mediatek,mt2701-jpgdec";
+ reg = <0 0x15004000 0 0x1000>;
+ interrupts = ;
+ clocks = <&imgsys CLK_IMG_JPGDEC_SMI>,
+ <&imgsys CLK_IMG_JPGDEC>;
+ clock-names = "jpgdec-smi",
+ "jpgdec";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <&larb2>;
+ iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
+<&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
+ };
--
1.9.1
[PATCH v9 3/4] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
---
This patch depends on:
CCF "Add clock support for Mediatek MT2701"[1]
iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
arch/arm/boot/dts/mt2701.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
};
+ jpegdec: jpegdec@15004000 {
+ compatible = "mediatek,mt2701-jpgdec";
+ reg = <0 0x15004000 0 0x1000>;
+ interrupts = ;
+ clocks = <&imgsys CLK_IMG_JPGDEC_SMI>,
+ <&imgsys CLK_IMG_JPGDEC>;
+ clock-names = "jpgdec-smi",
+ "jpgdec";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ mediatek,larb = <&larb2>;
+ iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
+<&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
+ };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
--
1.9.1
[PATCH v9 4/4] vcodec: mediatek: Add Maintainers entry for Mediatek JPEG driver
Signed-off-by: Rick Chang Signed-off-by: Minghsiu Tsai Signed-off-by: Bin Liu --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 93e9f42..6f68fb6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7818,6 +7818,13 @@ L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/mediatek/ +MEDIATEK JPEG DRIVER +M: Rick Chang +M: Bin Liu +S: Supported +F: drivers/media/platform/mtk-jpeg/ +F: Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt + MEDIATEK MEDIA DRIVER M: Tiffany Lin M: Andrew-CT Chen -- 1.9.1
[PATCH v9 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
Add v4l2 driver for Mediatek JPEG Decoder
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
---
drivers/media/platform/Kconfig | 15 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/mtk-jpeg/Makefile |2 +
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 1306 ++
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 139 +++
drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c| 417 +++
drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h| 91 ++
drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c | 160 +++
drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h | 25 +
drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 58 +
10 files changed, 2215 insertions(+)
create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_MEDIATEK_JPEG
+ tristate "Mediatek JPEG Codec driver"
+ depends on MTK_IOMMU_V1 || COMPILE_TEST
+ depends on VIDEO_DEV && VIDEO_V4L2
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on HAS_DMA
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..b10183f
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1306 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai
+ * Rick Chang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .colplanes = 1,
+ .flags = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV420M,
+ .h_sample = {4, 2, 2},
+ .v_sample = {4, 2, 2},
+ .colplanes = 3,
+ .h_align= 5,
+ .v_align= 4,
+ .flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV422M,
+ .h_sample = {4, 2, 2},
+ .v_sample = {4, 4, 4},
+ .colplanes = 3,
+ .h_align= 5,
+ .v_align= 3,
+ .flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+
Re: linux-next: build warning after merge of the tip tree
Stephen, Ingo,
CC'ing David.
On 14.12.2016 08:24, Ingo Molnar wrote:
>
> * Stephen Rothwell wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> produced this warning:
>>
>> fs/ubifs/dir.c: In function 'ubifs_readdir':
>> fs/ubifs/dir.c:629:13: warning: 'fstr_real_len' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
>> fstr.len = fstr_real_len;
>> ^
>>
>> Introduced by commit
>>
>> f4f61d2cc6d8 ("ubifs: Implement encrypted filenames")
>>
>> This is a false positive because assignment and use are both protected by
>> "if (encrypted)".
>>
>> I have no idea why this did not turn up earlier in my builds.
>
> FYI, f4f61d2cc6d8 is not in the -tip tree, so it cannot possibly have
> introduced
> this warning.
The commit comes via my UBIFS tree. But I never saw this warning, I'm testing
with both gcc-4.8 and gcc-6.1.
Let me investigate into that.
Does today's tip change some compiler flags?
Thanks,
//richard
Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm
On Wed, 14 Dec 2016, Roland Scheidegger wrote: > Am 13.12.2016 um 17:46 schrieb Thomas Gleixner: > > What are the adjust values after a warm boot? > > So, after cold boot with a kernel which doesn't adjust TSCs, then warm > boot I got: > [0.00] TSC ADJUST: CPU0: -602358264300 176072418728 > [0.00] TSC ADJUST: Boot CPU0: -602358264300 > [0.172245] TSC ADJUST: CPU1: -602360207584 176587932558 > [0.172245] TSC ADJUST differs: Reference CPU0: -602358264300 CPU1: > -602360207584 > [0.172246] TSC ADJUST synchronize: Reference CPU0: -602358264300 > CPU1: -602360207584 > [0.252663] TSC ADJUST: CPU2: -602359000822 176828627154 > [0.252663] TSC ADJUST differs: Reference CPU0: -602358264300 CPU2: > -602359000822 > [0.252664] TSC ADJUST synchronize: Reference CPU0: -602358264300 > CPU2: -602359000822 > [0.337014] TSC ADJUST: CPU3: -602360177680 177081093132 > [0.337014] TSC ADJUST differs: Reference CPU0: -602358264300 CPU3: > -602360177680 > [0.337015] TSC ADJUST synchronize: Reference CPU0: -602358264300 > CPU3: -602360177680 > > and so on. > > Albeit after another reboot (some minutes later), it actually straight > locked up again: > > TSC ADJUST: CPU1: -8257481427958 165112676430 > TSC ADJUST differs: Reference CPU0: -8257479484330 CPU1: -8257481427958 > TSC ADJUST synchronize: Reference CPU0: -8257479484330 CPU1: -8254781427958 > TSC target sync skip > ... > smpboot: Target CPU is online > > So, actually I thought the TSC would get reset too on warm boot, but > clearly looks like that isn't the case... > But I don't know what's the difference between first and second reboot - > the adjust values have just more magnitude, but otherwise even the > direction of the adjustments and everything looks all the same (just > like cold boot, which also looks all the same to me). I haven't found a pattern for the lockups yet and we have to wait for Intel to provide useful information about that issue. All we know so far is that negative adjust values are dangerous. Could you test the two patches on top of tip x86/timers branch so we can make progress with that whole disaster while waiting for Intel to come forth with a proper explanation? Thanks, tglx
[PATCH v2] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2
On vf610, PLL1 and PLL2 have registers to configure fractional part of
frequency multiplier.
This patch adds support for these registers.
This fixes "fast system clock" issue on boards where bootloader sets
fractional multiplier for PLL1.
Suggested-by: Andrey Smirnov
CC: Chris Healy
Signed-off-by: Nikita Yushchenko
---
This version restructures the patch:
- introduce explicit structure to store mf (multiply factor) consisting of
integer part, numenator and denumenator;
- provides routines that:
- calculate rate based on parent rate and mf,
- read mf from hw,
- write mf to hw,
- calculate best mf for wanted rate;
- implement recalc_rate() / round_rate() / set_rate() based on these.
drivers/clk/imx/clk-pllv3.c | 110
drivers/clk/imx/clk-vf610.c | 4 +-
drivers/clk/imx/clk.h | 1 +
3 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 7a6acc3e4a92..89ab42e7d6c0 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -21,6 +21,9 @@
#define PLL_NUM_OFFSET 0x10
#define PLL_DENOM_OFFSET 0x20
+#define PLL_VF610_NUM_OFFSET 0x20
+#define PLL_VF610_DENOM_OFFSET 0x30
+
#define BM_PLL_POWER (0x1 << 12)
#define BM_PLL_LOCK(0x1 << 31)
#define IMX7_ENET_PLL_POWER(0x1 << 5)
@@ -292,6 +295,110 @@ static const struct clk_ops clk_pllv3_av_ops = {
.set_rate = clk_pllv3_av_set_rate,
};
+struct clk_pllv3_vf610_mf {
+ u32 mfi;/* integer part, can be 20 or 22 */
+ u32 mfn;/* numinator, 30-bit value */
+ u32 mfd;/* denomenator, 30-bit value, must be less than mfn */
+};
+
+static unsigned long clk_pllv3_vf610_calc_rate(unsigned long parent_rate,
+ struct clk_pllv3_vf610_mf *mf)
+{
+ u64 temp64;
+
+ temp64 = parent_rate;
+ temp64 *= mf->mfn;
+ do_div(temp64, mf->mfd);
+
+ return (parent_rate * mf->mfi) + temp64;
+}
+
+static void clk_pllv3_vf610_mf_from_hw(struct clk_hw *hw,
+ struct clk_pllv3_vf610_mf *mf)
+{
+ struct clk_pllv3 *pll = to_clk_pllv3(hw);
+
+ mf->mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
+ mf->mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
+ mf->mfi = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
+}
+
+static void clk_pllv3_vf610_mf_to_hw(struct clk_hw *hw,
+ struct clk_pllv3_vf610_mf *mf)
+{
+ struct clk_pllv3 *pll = to_clk_pllv3(hw);
+ u32 val;
+
+ val = readl_relaxed(pll->base);
+ if (mf->mfi == 20)
+ val &= ~pll->div_mask; /* clear bit for mfi=20 */
+ else
+ val |= pll->div_mask; /* set bit for mfi=22 */
+ writel_relaxed(val, pll->base);
+
+ writel_relaxed(mf->mfn, pll->base + PLL_VF610_NUM_OFFSET);
+ writel_relaxed(mf->mfd, pll->base + PLL_VF610_DENOM_OFFSET);
+}
+
+static void clk_pllv3_vf610_mf_for_rate(unsigned long rate,
+ unsigned long parent_rate, struct clk_pllv3_vf610_mf *mf)
+{
+ u64 temp64;
+
+ mf->mfi = (rate >= 22 * parent_rate) ? 22 : 20;
+ mf->mfd = 0x3fff; /* use max supported value for best accuracy */
+
+ if (rate <= parent_rate * mf->mfi)
+ mf->mfn = 0;
+ else if (rate >= parent_rate * (mf->mfi + 1))
+ mf->mfn = mf->mfd - 1;
+ else {
+ /* rate = parent_rate * (mfi + mfn/mfd) */
+ temp64 = rate - parent_rate * mf->mfi;
+ temp64 *= mf->mfd;
+ do_div(temp64, parent_rate);
+ mf->mfn = temp64;
+ }
+}
+
+static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_pllv3_vf610_mf mf;
+
+ clk_pllv3_vf610_mf_from_hw(hw, &mf);
+ return clk_pllv3_vf610_calc_rate(parent_rate, &mf);
+}
+
+static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct clk_pllv3_vf610_mf mf;
+
+ clk_pllv3_vf610_mf_for_rate(rate, *prate, &mf);
+ return clk_pllv3_vf610_calc_rate(*prate, &mf);
+}
+
+static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_pllv3_vf610_mf mf;
+
+ clk_pllv3_vf610_mf_for_rate(rate, parent_rate, &mf);
+ clk_pllv3_vf610_mf_to_hw(hw, &mf);
+
+ return clk_pllv3_wait_lock(to_clk_pllv3(hw));
+}
+
+static const struct clk_ops clk_pllv3_vf610_ops = {
+ .prepare= clk_pllv3_prepare,
+ .unprepare = clk_pllv3_unprepare,
+ .is_prepared= clk_pllv3_is_prepared,
+ .recalc_rate= clk_pllv3_vf610_recalc_rate,
+ .round_rate = clk_pllv3_vf610_round_rate,
+ .set_rate = clk_pllv3_vf610_set_rate,
+};
+
static unsi
Re: [PATCH] vhost: introduce O(1) vq metadata cache
Hi Jason,
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on v4.9 next-20161214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jason-Wang/vhost-introduce-O-1-vq-metadata-cache/20161214-160153
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: i386-randconfig-x005-201650 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/vhost/vhost.c: In function 'vhost_vq_meta_fetch':
>> drivers/vhost/vhost.c:719:9: warning: cast to pointer from integer of
>> different size [-Wint-to-pointer-cast]
return (void *)(node->userspace_addr + (u64)addr - node->start);
^
vim +719 drivers/vhost/vhost.c
703 node->start,
704 node->size))
705 return 0;
706 }
707 return 1;
708 }
709
710 static inline void __user *vhost_vq_meta_fetch(struct vhost_virtqueue
*vq,
711 u64 addr, unsigned int
size,
712 int type)
713 {
714 const struct vhost_umem_node *node = vq->meta_iotlb[type];
715
716 if (!node)
717 return NULL;
718
> 719 return (void *)(node->userspace_addr + (u64)addr - node->start);
720 }
721
722 /* Can we switch to this memory table? */
723 /* Caller should have device mutex but not vq mutex */
724 static int memory_access_ok(struct vhost_dev *d, struct vhost_umem
*umem,
725 int log_all)
726 {
727 int i;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] cifs: Fix smbencrypt() to stop pointing a scatterlist at the stack
merged into cifs-2.6.git for-next
On Tue, Dec 13, 2016 at 7:07 AM, Jeff Layton wrote:
> On Mon, 2016-12-12 at 12:54 -0800, Andy Lutomirski wrote:
>> smbencrypt() points a scatterlist to the stack, which is breaks if
>> CONFIG_VMAP_STACK=y.
>>
>> Fix it by switching to crypto_cipher_encrypt_one(). The new code
>> should be considerably faster as an added benefit.
>>
>> This code is nearly identical to some code that Eric Biggers
>> suggested.
>>
>> Cc: sta...@vger.kernel.org # 4.9 only
>> Reported-by: Eric Biggers
>> Signed-off-by: Andy Lutomirski
>> ---
>>
>> Compile-tested only.
>>
>> fs/cifs/smbencrypt.c | 40
>> 1 file changed, 8 insertions(+), 32 deletions(-)
>>
>> diff --git a/fs/cifs/smbencrypt.c b/fs/cifs/smbencrypt.c
>> index 699b7868108f..c12bffefa3c9 100644
>> --- a/fs/cifs/smbencrypt.c
>> +++ b/fs/cifs/smbencrypt.c
>> @@ -23,7 +23,7 @@
>> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>> */
>>
>> -#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -69,46 +69,22 @@ str_to_key(unsigned char *str, unsigned char *key)
>> static int
>> smbhash(unsigned char *out, const unsigned char *in, unsigned char *key)
>> {
>> - int rc;
>> unsigned char key2[8];
>> - struct crypto_skcipher *tfm_des;
>> - struct scatterlist sgin, sgout;
>> - struct skcipher_request *req;
>> + struct crypto_cipher *tfm_des;
>>
>> str_to_key(key, key2);
>>
>> - tfm_des = crypto_alloc_skcipher("ecb(des)", 0, CRYPTO_ALG_ASYNC);
>> + tfm_des = crypto_alloc_cipher("des", 0, 0);
>> if (IS_ERR(tfm_des)) {
>> - rc = PTR_ERR(tfm_des);
>> - cifs_dbg(VFS, "could not allocate des crypto API\n");
>> - goto smbhash_err;
>> - }
>> -
>> - req = skcipher_request_alloc(tfm_des, GFP_KERNEL);
>> - if (!req) {
>> - rc = -ENOMEM;
>> cifs_dbg(VFS, "could not allocate des crypto API\n");
>> - goto smbhash_free_skcipher;
>> + return PTR_ERR(tfm_des);
>> }
>>
>> - crypto_skcipher_setkey(tfm_des, key2, 8);
>> -
>> - sg_init_one(&sgin, in, 8);
>> - sg_init_one(&sgout, out, 8);
>> + crypto_cipher_setkey(tfm_des, key2, 8);
>> + crypto_cipher_encrypt_one(tfm_des, out, in);
>> + crypto_free_cipher(tfm_des);
>>
>> - skcipher_request_set_callback(req, 0, NULL, NULL);
>> - skcipher_request_set_crypt(req, &sgin, &sgout, 8, NULL);
>> -
>> - rc = crypto_skcipher_encrypt(req);
>> - if (rc)
>> - cifs_dbg(VFS, "could not encrypt crypt key rc: %d\n", rc);
>> -
>> - skcipher_request_free(req);
>> -
>> -smbhash_free_skcipher:
>> - crypto_free_skcipher(tfm_des);
>> -smbhash_err:
>> - return rc;
>> + return 0;
>> }
>>
>> static int
>
> Acked-by: Jeff Layton
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
Steve
Re: [PATCH] [PATCH] GenWQE: drop duplicate headers
Hi Geliang, > On 28 Nov 2016, at 15:15, Geliang Tang wrote: > > On Thu, Nov 24, 2016 at 01:51:57PM +0100, Frank Haverkamp wrote: >> Hi Geliang, >> >> thanks for the simplification. Did you find those by manual inspection, or >> did you use a tool? >> >> Acked-by: Frank Haverkamp > > Hi Frank, > > Thanks for your review. > > I found those duplicate headers by a simple script written by myself. > I should have used scripts/checkincludes.pl to do this. Now I am using > scripts/checkincludes.pl to check GenWQE files, and I found another > duplicate header dma-mapping.h. So I updated this patch. > Nice. Thanks for checking our code. > -Geliang > > Geliang Tang (1): > GenWQE: drop duplicate headers > > drivers/misc/genwqe/card_base.c | 1 - > drivers/misc/genwqe/card_ddcb.c | 1 - > drivers/misc/genwqe/card_utils.c | 2 -- > 3 files changed, 4 deletions(-) > > -- > 2.9.3 > I am ok with the updated version too. Acked-by: Frank Haverkamp Frank
RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration
> fast (de)inflating & fast live migration > > Hello, > > On Fri, Dec 09, 2016 at 05:35:45AM +, Li, Liang Z wrote: > > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > > > What's the conclusion of your discussion? It seems you want some > > > > statistic before deciding whether to ripping the bitmap from the > > > > ABI, am I right? > > > > > > I think Andrea and David feel pretty strongly that we should remove > > > the bitmap, unless we have some data to support keeping it. I don't > > > feel as strongly about it, but I think their critique of it is > > > pretty valid. I think the consensus is that the bitmap needs to go. > > > > > > > Thanks for you clarification. > > > > > The only real question IMNHO is whether we should do a power-of-2 or > > > a length. But, if we have 12 bits, then the argument for doing > > > length is pretty strong. We don't need anywhere near 12 bits if doing > power-of-2. > > > > > So each item can max represent 16MB Bytes, seems not big enough, but > > enough for most case. > > Things became much more simple without the bitmap, and I like simple > > solution too. :) > > > > I will prepare the v6 and remove all the bitmap related stuffs. Thank you > > all! > > Sounds great! > > I suggested to check the statistics, because collecting those stats looked > simpler and quicker than removing all bitmap related stuff from the patchset. > However if you prefer to prepare a v6 without the bitmap another perhaps > more interesting way to evaluate the usefulness of the bitmap is to just run > the same benchmark and verify that there is no regression compared to the > bitmap enabled code. > > The other issue with the bitmap is, the best case for the bitmap is ever less > likely to materialize the more RAM is added to the guest. It won't regress > linearly because after all there can be some locality bias in the buddy > splits, > but if sync compaction is used in the large order allocations tried before > reaching order 0, the bitmap payoff will regress close to linearly with the > increase of RAM. > > So it'd be good to check the stats or the benchmark on large guests, at least > one hundred gigabytes or so. > > Changing topic but still about the ABI features needed, so it may be relevant > for this discussion: > > 1) vNUMA locality: i.e. allowing host to specify which vNODEs to take >memory from, using alloc_pages_node in guest. So you can ask to >take X pages from vnode A, Y pages from vnode B, in one vmenter. > > 2) allowing qemu to tell the guest to stop inflating the balloon and >report a fragmentation limit being hit, when sync compaction >powered allocations fails at certain power-of-two order granularity >passed by qemu to the guest. This order constraint will be passed >by default for hugetlbfs guests with 2MB hpage size, while it can >be used optionally on THP backed guests. This option with THP >guests would allow a highlevel management software to provide a >"don't reduce guest performance" while shrinking the memory size of >the guest from the GUI. If you deselect the option, you can shrink >down to the last freeable 4k guest page, but doing so may have to >split THP in the host (you don't know for sure if they were really >THP but they could have been), and it may regress >performance. Inflating the balloon while passing a minimum >granularity "order" of the pages being zapped, will guarantee >inflating the balloon cannot decrease guest performance >instead. Plus it's needed for hugetlbfs anyway as far as I can >tell. hugetlbfs would not be host enforceable even if the idea is >not to free memory but only reduce the available memory of the >guest (not without major changes that maps a hugetlb page with 4k >ptes at least). While for a more cooperative usage of hugetlbfs >guests, it's simply not useful to inflate the balloon at anything >less than the "HPAGE_SIZE" hugetlbfs granularity. > > We also plan to use userfaultfd to make the balloon driver host enforced (will > work fine on hugetlbfs 2M and tmpfs too) but that's going to be invisible to > the ABI so it's not strictly relevant for this discussion. > > On a side note, registering userfaultfd on the ballooned range, will keep > khugepaged at bay so it won't risk to re-inflating the MADV_DONTNEED > zapped sub-THP fragments no matter the sysfs tunings. > Thanks for your elaboration! > Thanks! > Andrea
[PATCH] 9p: safer definition of P9_NOTAG and P9_NOFID
Both defines should at least have enclosing parenthesis to be usable in
any syntactical situation. This is the case of U16_MAX and U32_MAX, so
let's use them.
This patch is just cleanup, it doesn't change any behaviour with the current
code.
Signed-off-by: Greg Kurz
---
include/net/9p/9p.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 27dfe85772b1..5c80d98126b3 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -332,8 +332,8 @@ enum p9_qid_t {
};
/* 9P Magic Numbers */
-#define P9_NOTAG (u16)(~0)
-#define P9_NOFID (u32)(~0)
+#define P9_NOTAG U16_MAX
+#define P9_NOFID U32_MAX
#define P9_MAXWELEM16
/* ample room for Twrite/Rread header */
Re: linux-next: build warning after merge of the tip tree
Hi Richard,
On Wed, 14 Dec 2016 09:05:10 +0100 Richard Weinberger wrote:
>
> The commit comes via my UBIFS tree. But I never saw this warning, I'm testing
> with both gcc-4.8 and gcc-6.1.
> Let me investigate into that.
>
> Does today's tip change some compiler flags?
Linus' tree commit
a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"")
was introduced between -rc4 and -rc5 so it is not in your tree.
--
Cheers,
Stephen Rothwell
Re: linux-next: build warning after merge of the tip tree
* Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> fs/ubifs/dir.c: In function 'ubifs_readdir':
> fs/ubifs/dir.c:629:13: warning: 'fstr_real_len' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> fstr.len = fstr_real_len;
> ^
>
> Introduced by commit
>
> f4f61d2cc6d8 ("ubifs: Implement encrypted filenames")
>
> This is a false positive because assignment and use are both protected by
> "if (encrypted)".
>
> I have no idea why this did not turn up earlier in my builds.
FYI, f4f61d2cc6d8 is not in the -tip tree, so it cannot possibly have
introduced
this warning.
Thanks,
Ingo
Re: Documenting the ioctl interfaces to discover relationships between namespaces
On 12/12/2016 07:18 PM, Eric W. Biederman wrote:
> "Michael Kerrisk (man-pages)" writes:
>
>> On 12/11/2016 11:30 PM, Eric W. Biederman wrote:
>>> "Michael Kerrisk (man-pages)" writes:
>>>
[was: [PATCH 0/4 v3] Add an interface to discover relationships
between namespaces]
>>>
>>> One small comment below.
>>>
Introspecting namespace relationships
Since Linux 4.9, two ioctl(2) operations are provided to allow
introspection of namespace relationships (see user_namespaces(7)
and pid_namespaces(7)). The form of the calls is:
ioctl(fd, request);
In each case, fd refers to a /proc/[pid]/ns/* file.
NS_GET_USERNS
Returns a file descriptor that refers to the owning user
namespace for the namespace referred to by fd.
NS_GET_PARENT
Returns a file descriptor that refers to the parent names‐
pace of the namespace referred to by fd. This operation is
valid only for hierarchical namespaces (i.e., PID and user
namespaces). For user namespaces, NS_GET_PARENT is synony‐
mous with NS_GET_USERNS.
In each case, the returned file descriptor is opened with O_RDONLY
and O_CLOEXEC (close-on-exec).
By applying fstat(2) to the returned file descriptor, one obtains
a stat structure whose st_ino (inode number) field identifies the
owning/parent namespace. This inode number can be matched with
the inode number of another /proc/[pid]/ns/{pid,user} file to
determine whether that is the owning/parent namespace.
>>>
>>> Like all fstat inode comparisons to be fully accurate you need to
>>> compare both the st_ino and st_dev. I reserve the right for st_dev to
>>> be significant when comparing namespaces. Otherwise I might have to
>>> create a namespace of namespaces someday and that is ugly.
>>>
Either of these ioctl(2) operations can fail with the following
error:
EPERM The requested namespace is outside of the caller's names‐
pace scope. This error can occur if, for example, the own‐
ing user namespace is an ancestor of the caller's current
user namespace. It can also occur on attempts to obtain
the parent of the initial user or PID namespace.
Additionally, the NS_GET_PARENT operation can fail with the fol‐
lowing error:
EINVAL fd refers to a nonhierarchical namespace.
See the EXAMPLE section for an example of the use of these opera‐
tions.
>>
>> So, after playing with this a bit, I have a question.
>>
>> I gather that in order to, for example, elaborate the tree of user
>> namespaces on the system, one would use NS_GET_PARENT on each of
>> the /proc/*/ns/user files and match up the results. Right?
>>
>> What happens if one of the parent user namespaces contains no
>> processes? That is, the parent namespace exists by virtue of being
>> pinned because a proc/PID/ns/user file is open or bind mounted.
>> (Chrome seems to do this sort of dance with user namespaces, for
>> example.) How do we find the ancestor of *that* user namespace?
>
> What is returned from NS_GET_USERNS and NS_GET_PARENT is a file
> descriptor, that you can call NS_GET_PARENT on.
Thanks, Eric. While trying to solve the small task I set myself,
and probably confused by past discussions[1], I was overlooking
the obvious.
Cheers,
Michael
[1] https://lkml.org/lkml/2016/7/28/365
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
[tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start_cpu()
Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7 Gitweb: http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7 Author: Josh Poimboeuf AuthorDate: Tue, 13 Dec 2016 21:25:35 -0600 Committer: Ingo Molnar CommitDate: Wed, 14 Dec 2016 08:48:05 +0100 x86/boot/64: Use 'push' instead of 'call' in start_cpu() start_cpu() pushes a text address on the stack so that stack traces from idle tasks will show start_cpu() at the end. But it uses a call instruction to do that, which is rather obtuse. Use a straightforward push instead. Suggested-by: Borislav Petkov Signed-off-by: Josh Poimboeuf Cc: Andy Lutomirski Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/4d8a1952759721d42d1e62ba9e4a7e3ac5df8574.1481685203.git.jpoim...@redhat.com Signed-off-by: Ingo Molnar --- arch/x86/kernel/head_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 90de288..1facaf4 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -298,7 +298,7 @@ ENTRY(start_cpu) * REX.W + FF /5 JMP m16:64 Jump far, absolute indirect, * address given in m16:64. */ - call1f # put return address on stack for unwinder + pushq $1f # put return address on stack for unwinder 1: xorq%rbp, %rbp # clear frame pointer movqinitial_code(%rip), %rax pushq $__KERNEL_CS# set correct cs
[tip:x86/urgent] x86/boot/64: Push correct start_cpu() return address
Commit-ID: 31dcfec11f827e9a5d8720fe4728f1305894884f Gitweb: http://git.kernel.org/tip/31dcfec11f827e9a5d8720fe4728f1305894884f Author: Josh Poimboeuf AuthorDate: Tue, 13 Dec 2016 21:25:36 -0600 Committer: Ingo Molnar CommitDate: Wed, 14 Dec 2016 08:48:05 +0100 x86/boot/64: Push correct start_cpu() return address start_cpu() pushes a text address on the stack so that stack traces from idle tasks will show start_cpu() at the end. But it currently shows the wrong function offset. It's more correct to show the address immediately after the 'lretq' instruction. Signed-off-by: Josh Poimboeuf Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/2cadd9f16c77da7ee7957bfc5e1c67928c23ca48.1481685203.git.jpoim...@redhat.com Signed-off-by: Ingo Molnar --- arch/x86/kernel/head_64.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 1facaf4..b467b14 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -298,12 +298,13 @@ ENTRY(start_cpu) * REX.W + FF /5 JMP m16:64 Jump far, absolute indirect, * address given in m16:64. */ - pushq $1f # put return address on stack for unwinder -1: xorq%rbp, %rbp # clear frame pointer + pushq $.Lafter_lret # put return address on stack for unwinder + xorq%rbp, %rbp # clear frame pointer movqinitial_code(%rip), %rax pushq $__KERNEL_CS# set correct cs pushq %rax# target address in negative space lretq +.Lafter_lret: ENDPROC(start_cpu) #include "verify_cpu.S"
Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs
Andy Lutomirski wrote: > > - sg_set_buf(&sg_out[1], pad, sizeof pad); > > + sg_set_buf(&sg_out[1], empty_zero_page, 16); > > My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what > exactly is the code trying to do? The old code makes no sense. It's > setting the *output* buffer to zeroed padding. Padding goes into the encrypt function and is going to come out of the decrypt function. Possibly derived_key_decrypt() should be checking that the padding that comes out is actually a bunch of zeros. Maybe we don't actually need to get the padding out, but I'm not sure whether the crypto layer will malfunction if we don't give it a buffer for the padding. David
Re: [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs
On Tue, Dec 13, 2016 at 04:54:30PM -0600, Segher Boessenkool wrote: > On Tue, Dec 13, 2016 at 09:39:55PM +0100, christophe leroy wrote: > > Le 13/12/2016 à 20:15, Segher Boessenkool a écrit : > > >On Tue, Dec 13, 2016 at 07:19:41PM +0100, Christophe Leroy wrote: > > >>At exception prologs, once SRR0 and SRR1 have been saved, MSR RI is > > >>set to mark the interrupt as recoverable. > > >> > > >>MSR RI has to be unset before writing into SRR0 and SRR1 at exception > > >>epilogs. > > > > > >Why? What goes wrong without this? Etc. > > > > The following patch implements perf instruction counting using the 8xx > > debug counters. When the counter reaches 0, it fires a debug exception. > > If that exception happens between the setting of srr0/srr1 and the rfi, > > values set to srr0/srr1 are lost and we end up with an Oops. > > > > To avoid that, MSR RI has to be unset. That way, because the debug > > counters mode is set to masked mode in register LCTRL2, no debug > > interrupt will happen during that critical phase. > > Okay, so why then do you do an expensive sequence on all other processors? > Does ppc32 support runtime code patching? If so, you could perhaps utilize that to only inflict the painful code sequence when perf is enabled.
Re: [PATCH 08/12] misc: Flexcard misc device support
On Wednesday, December 14, 2016 1:11:49 AM CET Holger Dengler wrote: > The Flexcard PCI BAR0 contain registers for configuration but also > for informational purpose like error counter, statistical information > and some timestamps. The read-only mmap of the misc device offers the > userspace a fast access to these registers. > > Signed-off-by: Benedikt Spranger > Signed-off-by: Holger Dengler > cc: Arnd Bergmann > cc: Greg Kroah-Hartman > --- > drivers/mfd/Kconfig | 1 + > drivers/misc/Kconfig | 6 ++ > drivers/misc/Makefile| 1 + > drivers/misc/flexcard_misc.c | 165 > +++ > 4 files changed, 173 insertions(+) > create mode 100644 drivers/misc/flexcard_misc.c > Maybe this could fit better in drivers/uio/ than drivers/misc? It seems to only export a memory mapped device. Arnd
Re: [PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update
On 13/12/16 19:35, Laurent Pinchart wrote: > Hi Sebastian, > > Thank you for the patch. > > On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel wrote: >> This is a workaround for a hardware bug occuring >> on OMAP3 with manually updated panels. > > Could you please explain what the bug is and how the workaround operates ? Do > you have a reference to an errata document ? I don't think I ever found out exactly why the problem happens. But on OMAP3 DSI, the fifo thresholds had to be tuned slightly, otherwise DISPC would stop. dispc_ovl_compute_fifo_thresholds() does that tuning if "manual_update" parameter is set on OMAP3. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 10/12] misc: Flexcard basic timestamp counter support
On Wednesday, December 14, 2016 1:11:51 AM CET Holger Dengler wrote: > The Eberspaecher Flexcard PMC II offers a Flexray network synchronized > counter with a selectable resolution of 1us, 100ns or 10ns. Add basic > support for the timestamp counter with 1us resolution, which is the > standard Flexray bus resolution. > > Signed-off-by: Benedikt Spranger > Signed-off-by: Holger Dengler > cc: Arnd Bergmann > cc: Greg Kroah-Hartman > Have you tried fitting this in the drivers/ptp/ framework rather than having your own posix clock for it? No idea if that works, it's just a thought I had. Arnd
Re: [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
On Tuesday, December 13, 2016 11:55:04 PM CET Jaghathiswari Rankappagounder
Natarajan wrote:
> Add clock, data and clear signal GPIO lines to control seven segment display
> on
> zaius platform.
>
> Signed-off-by: Jaghathiswari Rankappagounder Natarajan
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> index 8ef4ece..ccb8147 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> @@ -43,6 +43,14 @@
> gpios = <&gpio ASPEED_GPIO(H, 7) GPIO_ACTIVE_LOW>;
> };
> };
> +
> + seven-seg-disp {
> + compatible = "seven-seg-gpio-dev";
> + refresh-interval-ms = "1000";
> + clock-gpios = <&gpio ASPEED_GPIO(J, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_HIGH>;
> + clear-gpios = <&gpio ASPEED_GPIO(J, 1) GPIO_ACTIVE_HIGH>;
> + };
> };
According to your introductory mail, the interface is assumed to be
a 74HC164. Should we use that ID in the compatible string?
We can always add other strings later if we want to support multiple
wire formats.
Arnd
Re: [RFC PATCH] mm: introduce kv[mz]alloc helpers
On Tue 13-12-16 14:07:33, Joe Perches wrote:
> On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote:
> > Are there any more comments or objections to this patch? Is this a good
> > start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> > well in the initial version.
>
> Did Andrew Morton ever comment on this?
> I believe he was the primary objector in the past.
>
> Last I recollect was over a year ago:
>
> https://lkml.org/lkml/2015/7/7/1050
Let me quote:
: Sigh. We've resisted doing this because vmalloc() is somewhat of a bad
: thing, and we don't want to make it easy for people to do bad things.
:
: And vmalloc is bad because a) it's slow and b) it does GFP_KERNEL
: allocations for page tables and c) it is susceptible to arena
: fragmentation.
:
: We'd prefer that people fix their junk so it doesn't depend upon large
: contiguous allocations. This isn't userspace - kernel space is hostile
: and kernel code should be robust.
:
: So I dunno. Should we continue to make it a bit more awkward to use
: vmalloc()? Probably that tactic isn't being very successful - people
: will just go ahead and open-code it. And given the surprising amount
: of stuff you've placed in kvmalloc_node(), they'll implement it
: incorrectly...
:
: How about we compromise: add kvmalloc_node(), but include a BUG_ON("you
: suck") to it?
While I agree with some of those points, the reality really sucks,
though. We have tried the same tactic with __GFP_NOFAIL and failed as
well. I guess we should just bite the bullet and provide an api which is
so common that people keep reinventing their own ways around that, many
times wrongly or suboptimally. BUG_ON("you suck") is just not going to
help much I am afraid.
What do you think Andrew?
--
Michal Hocko
SUSE Labs
Re: [PATCH V4] i2c: designware: fix wrong Tx/Rx FIFO for ACPI
On 12/14/2016 05:20 AM, Tin Huynh wrote:
On Tue, Dec 13, 2016 at 6:25 PM, Andy Shevchenko
+ param = i2c_dw_read_comp_param(dev);
+ tx_fifo_depth = ((param >> 16) & 0xff) + 1;
+ rx_fifo_depth = ((param >> 8) & 0xff) + 1;
+ if (!dev->tx_fifo_depth) {
+ dev->tx_fifo_depth = tx_fifo_depth;
+ dev->rx_fifo_depth = rx_fifo_depth;
+ dev->adapter.nr = id;
+ } else if (tx_fifo_depth > 1) {
This makes sense now, though I would add a comment here and use >= 2 to
reflect datasheet.
/*
* Choose minimum values between HW and interface
* driver provided.
*/
I will implement as your comment. However , because adding 1 to the
value , can i use > 2 or >=3 ?
either > 1 or >= 2 since register value 0x01 from HW means FIFO depth 2
and register value 0x00 is reserved.
--
Jarkko
Re: [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
On Wednesday, December 14, 2016 9:55:47 AM CET Arnd Bergmann wrote: > According to your introductory mail, the interface is assumed to be > a 74HC164. Should we use that ID in the compatible string? > > We can always add other strings later if we want to support multiple > wire formats. Actually, looking up 74hc164, that seems to be a gpio expander, so maybe a more flexible way to do the same is to put a driver for the expander into drivers/gpio/ and have the main driver access the outputs of that using the gpiolib interface. Arnd
RE: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for fast (de)inflating & fast live migration
> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for > fast (de)inflating & fast live migration > > On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think > the > consensus is that the bitmap needs to go. > > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of order, If the MAX_ORDER is configured to a value bigger than 12, it will make things more complex to handle this case. If use order, we need to break a large memory range whose length is not the power of 2 into several small ranges, it also make the code complex. It seems we leave too many bit for the pfn, and the bits leave for length is not enough, How about keep 45 bits for the pfn and 19 bits for length, 45 bits for pfn can cover 57 bits physical address, that should be enough in the near feature. What's your opinion? thanks! Liang
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Michal Marek a écrit: [...] > Does the abidiff tool handle the case when an exported symbol is moved > between .c files? This is always a mess with genksyms, because the two > .c files have different includes and thus the type expansion stops at > different points. So typically the move needs to be reverted as a > workaround. Let's consider the function: 'void foo(struct S*);' If two ELF binaries contain a definition of that function foo which ELF symbol is exported, if the type struct S hasn't changed, and if the only difference between the ELF binaries is that foo was defined in the translation unit a.c in the first binary and in b.c in the second binary, then the comparison engine of libabigail (which is the library that abidiff uses) will consider the declarations of the two foo functions as being equal -- no matter what include file comes before the definition point of foo in a.c and b.c. If it does not, then it's a bug that ought to be fixed. If you feel that I haven't understood your question, then I guess a minimal standalone example (in the form of C source code) that illustrates your use case could be helpful to me. Thanks. -- Dodji
Re: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on
On Wed, Dec 14, 2016 at 2:18 AM, Max wrote:
> Without a bool string present, using "# CONFIG_DEVPORT is not set" in
> defconfig files would not actually unset devport. This ensured that
> /dev/port was always on, but there are reasons a user may wish to disable
> it (smaller kernel, attack surface reduction) if it's not being used. Adding
> a message here in order to make this user visible.
>
> Signed-off-by: Max Bires
> ---
> drivers/char/Kconfig | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 7ad3127..e8fc493 100644
>
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -589,10 +589,13 @@ config TELCLOCK
> controlling the behavior of this hardware.
>
> config DEVPORT
> - bool
> + bool "/dev/port character device"
bool "/dev/port character device" if EXPERT?
> depends on !M68K
> depends on ISA || PCI
> default y
> + help
> + Say Y here if you want to support the /dev/port device. The
> + /dev/port device is similar to /dev/mem, but for I/O ports.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
Hello Jagha,
On Wed, Dec 14, 2016 at 6:25 PM, Jaghathiswari Rankappagounder
Natarajan wrote:
> Add clock, data and clear signal GPIO lines to control seven segment display
> on
> zaius platform.
>
> Signed-off-by: Jaghathiswari Rankappagounder Natarajan
The Zaius device tree is not upstream. I suggest you submit it through
the Aspeed maintainer's tree (me!) for inclusion in the next merge
window.
For the time being, drop this patch from your series as it will not
apply to the upstream kernel.
As a general rule make sure you're basing the patches you send
upstream on a tag from an upstream tree. Linus' v4.9 tag would be the
best one at this point in time.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> index 8ef4ece..ccb8147 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> @@ -43,6 +43,14 @@
> gpios = <&gpio ASPEED_GPIO(H, 7) GPIO_ACTIVE_LOW>;
> };
> };
> +
> + seven-seg-disp {
> + compatible = "seven-seg-gpio-dev";
> + refresh-interval-ms = "1000";
> + clock-gpios = <&gpio ASPEED_GPIO(J, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_HIGH>;
> + clear-gpios = <&gpio ASPEED_GPIO(J, 1) GPIO_ACTIVE_HIGH>;
> + };
> };
>
> &fmc {
> --
> 2.8.0.rc3.226.g39d4020
>
Re: [PATCH v4 3/4] powernv: Pass PSSCR value and mask to power9_idle_stop
Hi Balbir,
Thanks for reviewing the patch. Please find my comments inline.
On Wed, Dec 14, 2016 at 11:16:26AM +1100, Balbir Singh wrote:
[..snip..]
> >
> > /*
> > - * r3 - requested stop state
> > + * r3 - PSSCR value corresponding to the requested stop state.
> > */
> > power_enter_stop:
> > #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> > @@ -274,9 +272,19 @@ power_enter_stop:
> > stb r4,HSTATE_HWTHREAD_STATE(r13)
> > #endif
> > /*
> > + * Check if we are executing the lite variant with ESL=EC=0
> > + */
> > + andis. r4, r3, PSSCR_EC_ESL_MASK_SHIFTED
>
> r4 = psscr & (PSSCR_EC | PSSCR_ESL)
>
> > + andi.r3, r3, PSSCR_RL_MASK /* r3 = requested stop state */
>
> r3 = psscr & RL_MASK (requested mask).
>
> Why do we do and andis. followed by andi. and a compdi below?
Do you mean why are we not using the CR0 value instead of using cmpdi
again ? Hmm.. The subsequent code expect r3 to contain only the RL
value. So, how about the following?
andi. r4, r3, PSSCR_RL_MASK;
andis. r3, r3, PSSCR_EC_ESL_MASK_SHIFTED;
mr r3, r4;
bne1f;
>
> > + cmpdir4, 0
>
> r4 == 0 implies we either both PSSCR_EC|ESL are cleared.
> I am not sure if our checks for EC are well defined/implemented.
> Should we worry about EC at all at this point?
Yes, we need to check the value of EC. Because if EC == 0, that
implies that the hardware will wake up from the stop instruction at
the subsequent instruction which we need to handle. This behaviour is
only available from POWER9 onwards, since on POWER8, the wakeup from
nap,sleep and winkle were always at 0x100. Hence the existing code
assumes that all the wakeups are at 0x100, which is what this patch
modifies.
>
> > + bne 1f
> > + IDLE_STATE_ENTER_SEQ(PPC_STOP)
> > + li r3,0 /* Since we didn't lose state, return 0 */
> > + b pnv_wakeup_noloss
> > +/*
> > * Check if the requested state is a deep idle state.
> > */
> > - LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
> > +1: LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
> > ld r4,ADDROFF(pnv_first_deep_stop_state)(r5)
> > cmpdr3,r4
> > bge 2f
> > @@ -353,16 +361,17 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S,
> > 66); \
> > ld r3,ORIG_GPR3(r1); /* Restore original r3 */ \
> > 20:nop;
> >
> > -
>
> Spurious change?
There were two empty lines for no particular reason. So got rid of one
of them.
>
> > /*
> > - * r3 - requested stop state
> > + * r3 - The PSSCR value corresponding to the stop state.
> > + * r4 - The PSSCR mask corrresonding to the stop state.
> > */
> > _GLOBAL(power9_idle_stop)
> > - LOAD_REG_IMMEDIATE(r4, PSSCR_HV_TEMPLATE)
> > - or r4,r4,r3
> > - mtspr SPRN_PSSCR, r4
> > - li r4, 1
> > + mfspr r5, SPRN_PSSCR
> > + andcr5, r5, r4
> > + or r3, r3, r5
> > + mtspr SPRN_PSSCR, r3
> > LOAD_REG_ADDR(r5,power_enter_stop)
> > + li r4, 1
> > b pnv_powersave_common
> > /* No return */
> > /*
[..snip..]
> > @@ -253,9 +259,11 @@ static void power9_idle(void)
> > u64 pnv_first_deep_stop_state = MAX_STOP_STATE;
> >
> > /*
> > - * Deepest stop idle state. Used when a cpu is offlined
> > + * psscr value and mask of the deepest stop idle state.
> > + * Used when a cpu is offlined.
> > */
> > -u64 pnv_deepest_stop_state;
> > +u64 pnv_deepest_stop_psscr_val;
> > +u64 pnv_deepest_stop_psscr_mask;
> >
> > /*
> > * Power ISA 3.0 idle initialization.
> > @@ -302,28 +310,58 @@ static int __init pnv_arch300_idle_init(struct
> > device_node *np, u32 *flags,
> > int dt_idle_states)
>
> In some cases we say power9 and arch300 in others, not related to
> > this patchset, but just a generic comment
Will see if I can make this consistent.
[..snip..]
> > @@ -333,12 +371,27 @@ static int __init pnv_arch300_idle_init(struct
> > device_node *np, u32 *flags,
> > (pnv_first_deep_stop_state > psscr_rl))
> > pnv_first_deep_stop_state = psscr_rl;
> >
> > - if (pnv_deepest_stop_state < psscr_rl)
> > - pnv_deepest_stop_state = psscr_rl;
> > - }
> > + if (max_residency_ns < residency_ns[i]) {
> > + max_residency_ns = residency_ns[i];
> > + pnv_deepest_stop_psscr_val =
> > + compute_psscr_val(psscr_val[i], psscr_mask[i]);
> > + pnv_deepest_stop_psscr_mask =
> > + compute_psscr_mask(psscr_mask[i]);
> > + }
> >
>
> Does it make sense to have them sorted and then use the last value
> from the array?
Yes, if the firmware can be relied upon to do this, we can obtain the
deepest_stop_psscr_val and the mask in constant time.
However, this init function is called only once during the boot, and
we are anyway iterating over all the idle states to find the first
deep stop state and the default s
Re: [PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update
Hi Tomi, On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote: > On 13/12/16 19:35, Laurent Pinchart wrote: > > On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel wrote: > >> This is a workaround for a hardware bug occuring > >> on OMAP3 with manually updated panels. > > > > Could you please explain what the bug is and how the workaround operates ? > > Do you have a reference to an errata document ? > > I don't think I ever found out exactly why the problem happens. But on > OMAP3 DSI, the fifo thresholds had to be tuned slightly, otherwise DISPC > would stop. dispc_ovl_compute_fifo_thresholds() does that tuning if > "manual_update" parameter is set on OMAP3. I've had a look at dispc_ovl_compute_fifo_thresholds() and the patch makes sense to me. If Sebastian could address the small issues I pointed out, we could then merge this. Alternatively I can take care of addressing them. -- Regards, Laurent Pinchart
Re: usb/gadget: warning in ep_write_iter/__alloc_pages_nodemask
On Tue 13-12-16 08:33:34, Alan Stern wrote: > On Tue, 13 Dec 2016, Michal Hocko wrote: > > > > > That being said, what ep_write_iter does sounds quite stupit. It just > > > > allocates a large continuous buffer which seems to be under user > > > > control... Aka no good! It should do that per pages or something like > > > > that. Something worth fixing > > > > > > It's not important enough to make the driver do all this work. If > > > users want to send large amounts of data, they can send it a page at a > > > time (or something like that). > > > > Is it really necessary to allocate the full iov_iter_count? Why cannot > > we process the from buffer one page at a time? > > We could (although one page is really too small -- USB 3.1 can transfer > 800 KB per ms so we ought to handle at least 128 KB at a time). Is there any problem to submit larger transfers without having the buffer physically contiguous? > But > turn the argument around: If the user wants to transfer that much data, > why can't he _submit_ it one page at a time? Not sure I understand. > > > If you really want to prevent the driver from attempting to allocate a > > > large buffer, all that's needed is an upper limit on the total size. > > > For example, 64 KB. > > > > Well, my point was that it is not really hard to imagine to deplete > > larger contiguous memory blocks (say PAGE_ALLOC_COSTLY_ORDER). Those are > > still causing the OOM killer and chances are that a controlled flood of > > these requests could completely DoS the system. > > Putting a limit on the total size of a single transfer would prevent > this. Dunno, putting a limit to the user visible interface sounds wrong to me. -- Michal Hocko SUSE Labs
Re: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on
On Wednesday, December 14, 2016 9:58:53 AM CET Geert Uytterhoeven wrote: > > > > --- a/drivers/char/Kconfig > > +++ b/drivers/char/Kconfig > > @@ -589,10 +589,13 @@ config TELCLOCK > > controlling the behavior of this hardware. > > > > config DEVPORT > > - bool > > + bool "/dev/port character device" > > bool "/dev/port character device" if EXPERT? I think the 'default y' is good enough, there are good reasons even for non-EXPERT configurations to turn this off. Arnd
[PATCH 1/2] mm: don't dereference struct page fields of invalid pages
The VM_BUG_ON() check in move_freepages() checks whether the node
id of a page matches the node id of its zone. However, it does this
before having checked whether the struct page pointer refers to a
valid struct page to begin with. This is guaranteed in most cases,
but may not be the case if CONFIG_HOLES_IN_ZONE=y.
So reorder the VM_BUG_ON() with the pfn_valid_within() check.
Signed-off-by: Ard Biesheuvel
---
mm/page_alloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f64e7bcb43b7..4e298e31fa86 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1864,14 +1864,14 @@ int move_freepages(struct zone *zone,
#endif
for (page = start_page; page <= end_page;) {
- /* Make sure we are not inadvertently changing nodes */
- VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
-
if (!pfn_valid_within(page_to_pfn(page))) {
page++;
continue;
}
+ /* Make sure we are not inadvertently changing nodes */
+ VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
+
if (!PageBuddy(page)) {
page++;
continue;
--
2.7.4
[PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
The NUMA code may get confused by the presence of NOMAP regions within zones, resulting in spurious BUG() checks where the node id deviates from the containing zone's node id. Since the kernel has no business reasoning about node ids of pages it does not own in the first place, enable CONFIG_HOLES_IN_ZONE to ensure that such pages are disregarded. Signed-off-by: Ard Biesheuvel --- arch/arm64/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 111742126897..0472afe64d55 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -614,6 +614,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK def_bool y depends on NUMA +config HOLES_IN_ZONE + def_bool y + depends on NUMA + source kernel/Kconfig.preempt source kernel/Kconfig.hz -- 2.7.4
[PATCH 0/2] arm64: numa: fix spurious BUG() on NOMAP regions
This fixes the issue reported by Robert Richter where the fact that the node id of struct pages covered by NOMAP regions is not initialized, triggering a VM_BUG_ON() in the mm code. I know that this approach is the least preferred option by Robert, but it has been used successfully in the downstream Linaro Enterprise kernel, running on HiSilicon D05, which suffered from the same issue as Cavium ThunderX where it was originally reported. Given that the other proposed solutions either fail to solve the issue completely, or cause regressions in other code (hibernate), I think this issue is appropriate for merging now, and backported to -stable. If there are performance concerns, we can try to improve on this solution, which could include reverting patch #2 altogether, for all I care. Patch #1 fixes a bug in the generic mm code where a struct page is dereferenced before pfn_valid() is called. This should probably go to stable regardless of where the arm64 discussion goes. Patch #2 enables CONFIG_HOLES_IN_ZONE for arm64 numa, causing the kernel to no longer assume that all pages in a zone have valid struct pages associated with them. Ard Biesheuvel (2): mm: don't dereference struct page fields of invalid pages arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA arch/arm64/Kconfig | 4 mm/page_alloc.c| 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-) -- 2.7.4
Re: [PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update
On 14/12/16 11:10, Laurent Pinchart wrote: > Hi Tomi, > > On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote: >> On 13/12/16 19:35, Laurent Pinchart wrote: >>> On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel wrote: This is a workaround for a hardware bug occuring on OMAP3 with manually updated panels. >>> >>> Could you please explain what the bug is and how the workaround operates ? >>> Do you have a reference to an errata document ? >> >> I don't think I ever found out exactly why the problem happens. But on >> OMAP3 DSI, the fifo thresholds had to be tuned slightly, otherwise DISPC >> would stop. dispc_ovl_compute_fifo_thresholds() does that tuning if >> "manual_update" parameter is set on OMAP3. > > I've had a look at dispc_ovl_compute_fifo_thresholds() and the patch makes > sense to me. If Sebastian could address the small issues I pointed out, we > could then merge this. Alternatively I can take care of addressing them. It's only needed with the rest of the DSI manual update series, so I'd rather keep it as part of that series. Tomi signature.asc Description: OpenPGP digital signature
Re: [RESEND PATCH v4 1/2] sysctl: introduce new proc handler proc_dobool
Thanks, this error is caused by # CONFIG_PROC_SYSCTL is not set Will fixed in next version Jia B.R. On 12/14/16 2:13 PM, kbuild test robot wrote: Hi Jia, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jia-He/sysctl-introduce-new-proc-handler-proc_dobool/20161214-112656 config: x86_64-randconfig-n0-12141159 (attached as .config) compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): kernel/built-in.o:(___ksymtab+proc_dobool+0x0): undefined reference to `proc_dobool' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v2 8/9] openrisc: Updates after openrisc.net has been lost
Hi Stafford, Stefan,
On Mon, Nov 14, 2016 at 2:30 PM, Stafford Horne wrote:
> The openrisc.net domain expired and was taken over by squatters.
> These updates point documentation to the new domain, mailing lists
> and git repos.
>
> Also, Jonas is not the main maintainer anylonger, he reviews changes
> but does not maintain a repo or sent pull requests. Updating this to
> add Stafford and Stefan who are the active maintainers.
>
> Signed-off-by: Stafford Horne
> ---
> MAINTAINERS | 6 --
> arch/openrisc/README.openrisc | 8
> arch/openrisc/kernel/setup.c | 2 +-
> 3 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 851b89b..d84a585 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8958,9 +8958,11 @@ F: drivers/of/resolver.c
>
> OPENRISC ARCHITECTURE
> M: Jonas Bonn
> -W: http://openrisc.net
> +M: Stefan Kristiansson
> +M: Stafford Horne
> +L: openr...@lists.librecores.org
> +W: http://openrisc.io
> S: Maintained
> -T: git git://openrisc.net/~jonas/linux
> F: arch/openrisc/
It's great news to see new active maintainers for OpenRISC.
Thanks a lot!
Somehow I seem to have missed the new mailing announcement.
Subscribed ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC 2/2] powerpc/8xx: Perf events on PPC 8xx
On Tue, Dec 13, 2016 at 07:19:43PM +0100, Christophe Leroy wrote:
> +int mpc8xx_pmu_event_init(struct perf_event *event)
> +{
> + int type = event_type(event);
> +
> + switch (type) {
> + case PERF_8xx_ID_CPU_CYCLES:
> + case PERF_8xx_ID_ITLB_LOAD_MISS:
> + case PERF_8xx_ID_DTLB_LOAD_MISS:
> + break;
> + case PERF_8xx_ID_HW_INSTRUCTIONS:
> + mtspr(SPRN_CMPA, 0);
Should that not live in init_mpc8xx_pmu() ?
Afaict its a one time setup thing.
> + break;
> + default:
> + return type;
> + }
> + return 0;
> +}
> +
> +int mpc8xx_pmu_add(struct perf_event *event, int flags)
> +{
> + int type = event_type(event);
> + s64 val;
> +
> + switch (type) {
> + case PERF_8xx_ID_CPU_CYCLES:
> + val = get_tb();
> + break;
> + case PERF_8xx_ID_HW_INSTRUCTIONS:
> + val = (instruction_counter << 16) | 0x;
> + mtspr(SPRN_COUNTA, 0x0001);
> + mtspr(SPRN_ICTRL, 0xc0080007);
> + break;
So this sets up the counter and starts counting, right?
What happens if someone adds two events of this type?
Also, typical implementations would do:
if (flags & PERF_EF_START)
mpc8xx_pmu_start(event, flags);
> + case PERF_8xx_ID_ITLB_LOAD_MISS:
> + val = itlb_miss_counter;
> + break;
> + case PERF_8xx_ID_DTLB_LOAD_MISS:
> + val = dtlb_miss_counter;
> + break;
> + default:
> + break;
> + }
> + local64_set(&event->hw.prev_count, val);
Right, so aside from that INSTRUCTION event, the rest is treated like
freerunning counters which is fine.
> + return 0;
> +}
> +
> +void mpc8xx_pmu_read(struct perf_event *event)
> +{
> + int type = event_type(event);
> + s64 prev, val, delta;
> +
> + prev = local64_read(&event->hw.prev_count);
> + switch (type) {
> + case PERF_8xx_ID_CPU_CYCLES:
> + val = get_tb();
> + delta = 16 * (val - prev);
> + break;
> + case PERF_8xx_ID_HW_INSTRUCTIONS:
> + mtspr(SPRN_ICTRL, 7);
> + val = (instruction_counter << 16) | (0x -
> (mfspr(SPRN_COUNTA) >> 16));
> + mtspr(SPRN_ICTRL, 0xc0080007);
> + delta = val - prev;
> + break;
> + case PERF_8xx_ID_ITLB_LOAD_MISS:
> + val = itlb_miss_counter;
> + delta = val - prev;
> + break;
> + case PERF_8xx_ID_DTLB_LOAD_MISS:
> + val = dtlb_miss_counter;
> + delta = val - prev;
> + break;
> + default:
> + break;
> + }
> + local64_set(&event->hw.prev_count, val);
> + local64_add(delta, &event->count);
> +}
So there is one case, where we group this event with a software hrtimer
event and the hrtimer would call ::read() from interrupt context while
you're already in ::read().
This seems to suggest you still need a cmpxchg() loop to update, no?
> +void mpc8xx_pmu_del(struct perf_event *event, int flags)
> +{
> + int type = event_type(event);
> + s64 prev, val;
> +
> + prev = local64_read(&event->hw.prev_count);
> + switch (type) {
> + case PERF_8xx_ID_HW_INSTRUCTIONS:
> + mtspr(SPRN_ICTRL, 7);
> + val = (instruction_counter << 16) | (0x -
> (mfspr(SPRN_COUNTA) >> 16));
> + local64_add(val - prev, &event->count);
> + break;
> + case PERF_8xx_ID_CPU_CYCLES:
> + case PERF_8xx_ID_ITLB_LOAD_MISS:
> + case PERF_8xx_ID_DTLB_LOAD_MISS:
> + mpc8xx_pmu_read(event);
> + break;
> + default:
> + break;
> + }
Right, so you make all del()'s imply PERF_EF_UPDATE, which is fine.
> +}
> +
> +void mpc8xx_pmu_start(struct perf_event *event, int flags)
> +{
> +}
> +
> +void mpc8xx_pmu_stop(struct perf_event *event, int flags)
> +{
> +}
So I think you can get away with doing this because the PMU doesn't do
sampling, which is what would normally start/stop already programmed
counters.
> +static struct pmu mpc8xx_pmu = {
> + .event_init = mpc8xx_pmu_event_init,
> + .add= mpc8xx_pmu_add,
> + .del= mpc8xx_pmu_del,
> + .start = mpc8xx_pmu_start,
> + .stop = mpc8xx_pmu_stop,
> + .read = mpc8xx_pmu_read,
.capabilities = PERF_PMU_CAP_NO_INTERRUPT |
PERF_PMU_CAP_NO_NMI,
> +};
> +
> +static int init_mpc8xx_pmu(void)
> +{
> + return perf_pmu_register(&mpc8xx_pmu, "cpu", PERF_TYPE_RAW);
> +}
> +
> +early_initcall(init_mpc8xx_pmu);
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-14 09:58, Dodji Seketeli wrote:
> Michal Marek a écrit:
>
> [...]
>
>> Does the abidiff tool handle the case when an exported symbol is moved
>> between .c files? This is always a mess with genksyms, because the two
>> .c files have different includes and thus the type expansion stops at
>> different points. So typically the move needs to be reverted as a
>> workaround.
>
> Let's consider the function:
>
> 'void foo(struct S*);'
>
> If two ELF binaries contain a definition of that function foo which ELF
> symbol is exported, if the type struct S hasn't changed, and if the only
> difference between the ELF binaries is that foo was defined in the
> translation unit a.c in the first binary and in b.c in the second
> binary, then the comparison engine of libabigail (which is the library
> that abidiff uses) will consider the declarations of the two foo
> functions as being equal -- no matter what include file comes before the
> definition point of foo in a.c and b.c. If it does not, then it's a bug
> that ought to be fixed.
>
> If you feel that I haven't understood your question, then I guess a
> minimal standalone example (in the form of C source code) that
> illustrates your use case could be helpful to me.
A minimal example would be
t1.c:
struct s1;
struct s2 {
int i;
}
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
}
void foo(struct s3*);
EXPORT_SYMBOL(foo);
t2.c:
struct s1 {
int j;
}
struct s2;
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
}
void foo(struct s3*);
EXPORT_SYMBOL(foo);
genksyms expands this to
void foo ( struct s3 { struct s1 { UNKNOWN } * ptr1 ; struct s2 { int i ; } *
ptr2 ; } * )
or
void foo ( struct s3 { struct s1 { int j ; } * ptr1 ; struct s2 { UNKNOWN } *
ptr2 ; } * )
respectively. The types are the same, but their visibility in the
different compilation units differs.
Michal
Re: [RFC PATCH] mm: introduce kv[mz]alloc helpers
On Tue 13-12-16 13:55:46, Andreas Dilger wrote: > On Dec 13, 2016, at 3:14 AM, Michal Hocko wrote: > > > > Are there any more comments or objections to this patch? Is this a good > > start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as > > well in the initial version. > > I'm in favour of this cleanup as a starting point. I definitely agree > that this same functionality is in use in a number of places and should > be consolidated. > > The vmalloc() from GFP_NOFS can be addressed separately in later patches. > That is an issue for several filesystems, and while XFS works around this, > it would be better to lift that out of the filesystem code into the VM. Well, my longer term plan is to change how GFP_NOFS is used from the fs code rather than tweak the VM layer. The current situation with the nofs is messy and confusing. In many contexts it is used without a good reason - just to be sure that nothing will break. I strongly believe that we should use a scope api [1] which marks whole regions of potentially reclaim dangerous code paths and all the allocations within that region will inherit the nofs protection automatically. That would solve the vmalloc(GFP_NOFS) problem as well. The route to get there is no short or easy. I am planning to repost the scope patchset hopefully soon with ext4 converted. [1] http://lkml.kernel.org/r/1461671772-1269-1-git-send-email-mho...@kernel.org > Really, there are several of things about vmalloc() that could improve > if we decided to move it out of the dog house and allow it to become a > first class citizen, but that needs a larger discussion, and you can > already do a lot of cleanup with just the introduction of kvmalloc(). > > Since this is changing the ext4 code, you can add my: > > Reviewed-by: Andreas Dilger thanks! -- Michal Hocko SUSE Labs
Re: [PATCH 10/12] misc: Flexcard basic timestamp counter support
On Wed, 14 Dec 2016, Arnd Bergmann wrote: > On Wednesday, December 14, 2016 1:11:51 AM CET Holger Dengler wrote: > > The Eberspaecher Flexcard PMC II offers a Flexray network synchronized > > counter with a selectable resolution of 1us, 100ns or 10ns. Add basic > > support for the timestamp counter with 1us resolution, which is the > > standard Flexray bus resolution. > > > > Signed-off-by: Benedikt Spranger > > Signed-off-by: Holger Dengler > > cc: Arnd Bergmann > > cc: Greg Kroah-Hartman > > > > Have you tried fitting this in the drivers/ptp/ framework rather > than having your own posix clock for it? It has nothing to do with PTP. It's a completely seperate clock and cannot be used for PTP style time synchronization. Thanks, tglx
[PATCH V5] i2c: designware: fix wrong Tx/Rx FIFO for ACPI
ACPI always sets Tx/Rx FIFO to 32. This configuration will
cause problem if the IP core supports a FIFO size of less than 32.
The driver should read the FIFO size from the IP and select the smaller
one of the two.
Signed-off-by: Tin Huynh
---
drivers/i2c/busses/i2c-designware-platdrv.c | 31 --
1 files changed, 24 insertions(+), 7 deletions(-)
Change from V4:
-Change else condition and add some comments to clarify new approach.
Change from V3:
-Use uppercase of FIFO instead of lowercase.
-Correct else condition when IP core return 0 of FIFO.
Change from V2:
-Add a helper function to set FIFO size.
Change from V1:
-Revert the default 32 for FIFO, read parameter from IP core
and pick the smaller one of the two.
-Correct the title to describe new approach.
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 0b42a12..682adc3 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -150,6 +150,29 @@ static int i2c_dw_plat_prepare_clk(struct dw_i2c_dev
*i_dev, bool prepare)
return 0;
}
+static void dw_i2c_set_fifo_size(struct dw_i2c_dev *dev, int id)
+{
+ u32 param, tx_fifo_depth, rx_fifo_depth;
+
+ /*
+* Try to detect the FIFO depth if not set by interface driver,
+* the depth could be from 2 to 256 from HW spec.
+*/
+ param = i2c_dw_read_comp_param(dev);
+ tx_fifo_depth = ((param >> 16) & 0xff) + 1;
+ rx_fifo_depth = ((param >> 8) & 0xff) + 1;
+ if (!dev->tx_fifo_depth) {
+ dev->tx_fifo_depth = tx_fifo_depth;
+ dev->rx_fifo_depth = rx_fifo_depth;
+ dev->adapter.nr = id;
+ } else if (tx_fifo_depth >= 2) {
+ dev->tx_fifo_depth = min_t(u32, dev->tx_fifo_depth,
+ tx_fifo_depth);
+ dev->rx_fifo_depth = min_t(u32, dev->rx_fifo_depth,
+ rx_fifo_depth);
+ }
+}
+
static int dw_i2c_plat_probe(struct platform_device *pdev)
{
struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
@@ -246,13 +269,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
100);
}
- if (!dev->tx_fifo_depth) {
- u32 param1 = i2c_dw_read_comp_param(dev);
-
- dev->tx_fifo_depth = ((param1 >> 16) & 0xff) + 1;
- dev->rx_fifo_depth = ((param1 >> 8) & 0xff) + 1;
- dev->adapter.nr = pdev->id;
- }
+ dw_i2c_set_fifo_size(dev, pdev->id);
adap = &dev->adapter;
adap->owner = THIS_MODULE;
--
1.7.1
Re: [PATCH v7 1/2] usb: xhci: plat: Enable runtime PM
Hi Robert,
On 14 December 2016 at 14:43, Robert Foss wrote:
> Hey Baolin,
>
> On 2016-12-12 12:21 AM, Baolin Wang wrote:
>>
>> Hi Robert,
>>
>> On 2 December 2016 at 05:46, Robert Foss
>> wrote:
>>>
>>> Enable runtime PM for the xhci-plat device so that the parent device
>>> may implement runtime PM.
>>>
>>> Signed-off-by: Robert Foss
>>>
>>> Tested-by: Robert Foss
>>> ---
>>> drivers/usb/host/xhci-plat.c | 29 +++--
>>> 1 file changed, 27 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index ed56bf9ed885..ba4efe74f537 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>> @@ -246,6 +246,9 @@ static int xhci_plat_probe(struct platform_device
>>> *pdev)
>>> if (ret)
>>> goto dealloc_usb2_hcd;
>>>
>>> + pm_runtime_set_active(&pdev->dev);
>>> + pm_runtime_enable(&pdev->dev);
>>
>>
>> You did not implement the runtime callbacks of xHCI device, then how
>> can the parent device control the resume/suspend of xHCI device by
>> runtime PM mechanism? Could you see my previous patch which implement
>> the runtime callbacks for xHCI device?
>> https://lkml.org/lkml/2016/11/28/25
>>
>
> Pardon my ignorance, but which exact functions need to be implemented?
> Also, does the lkml link you provided contain an example implementation of
> those functions?
Please check below link:
https://lkml.org/lkml/2016/12/13/32
https://lkml.org/lkml/2016/12/13/34
>
>
>>> +
>>> return 0;
>>>
>>>
>>> @@ -274,6 +277,8 @@ static int xhci_plat_remove(struct platform_device
>>> *dev)
>>> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>> struct clk *clk = xhci->clk;
>>>
>>> + pm_runtime_disable(&dev->dev);
>>> +
>>> usb_remove_hcd(xhci->shared_hcd);
>>> usb_phy_shutdown(hcd->usb_phy);
>>>
>>> @@ -292,6 +297,13 @@ static int xhci_plat_suspend(struct device *dev)
>>> {
>>> struct usb_hcd *hcd = dev_get_drvdata(dev);
>>> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>> + int ret;
>>> +
>>> + ret = pm_runtime_get_sync(dev);
>>> + if (ret < 0) {
>>> + pm_runtime_put(dev);
>>> + return ret;
>>> + }
>>>
>>> /*
>>> * xhci_suspend() needs `do_wakeup` to know whether host is
>>> allowed
>>> @@ -301,15 +313,28 @@ static int xhci_plat_suspend(struct device *dev)
>>> * reconsider this when xhci_plat_suspend enlarges its scope,
>>> e.g.,
>>> * also applies to runtime suspend.
>>> */
>>> - return xhci_suspend(xhci, device_may_wakeup(dev));
>>> + ret = xhci_suspend(xhci, device_may_wakeup(dev));
>>> + pm_runtime_put(dev);
>>> +
>>> + return ret;
>>> }
>>>
>>> static int xhci_plat_resume(struct device *dev)
>>> {
>>> struct usb_hcd *hcd = dev_get_drvdata(dev);
>>> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>> + int ret;
>>>
>>> - return xhci_resume(xhci, 0);
>>> + ret = pm_runtime_get_sync(dev);
>>> + if (ret < 0) {
>>> + pm_runtime_put(dev);
>>> + return ret;
>>> + }
>>> +
>>> + ret = xhci_resume(xhci, 0);
>>> + pm_runtime_put(dev);
>>> +
>>> + return ret;
>>> }
>>>
>>> static const struct dev_pm_ops xhci_plat_pm_ops = {
>>> --
>>> 2.11.0
>>>
>>
>>
>>
>
--
Baolin.wang
Best Regards
Re: [PATCH 08/12] misc: Flexcard misc device support
On 12/14/2016 09:42 AM, Arnd Bergmann wrote: > On Wednesday, December 14, 2016 1:11:49 AM CET Holger Dengler wrote: >> The Flexcard PCI BAR0 contain registers for configuration but also >> for informational purpose like error counter, statistical information >> and some timestamps. The read-only mmap of the misc device offers the >> userspace a fast access to these registers. >> >> Signed-off-by: Benedikt Spranger >> Signed-off-by: Holger Dengler >> cc: Arnd Bergmann >> cc: Greg Kroah-Hartman >> --- >> drivers/mfd/Kconfig | 1 + >> drivers/misc/Kconfig | 6 ++ >> drivers/misc/Makefile| 1 + >> drivers/misc/flexcard_misc.c | 165 >> +++ >> 4 files changed, 173 insertions(+) >> create mode 100644 drivers/misc/flexcard_misc.c >> > > Maybe this could fit better in drivers/uio/ than drivers/misc? It > seems to only export a memory mapped device. You're right, this patch only introduce the memory mapping. But the next patch in series add also some attributes to the device, therfore we put it in drivers/misc. > > Arnd > -- Gruß, Holger Dengler -- phone: +49 7556 25 999 14; fax: +49 7556 25 999 99 signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/6] clk: sunxi-ng: set the parent rate when adjustin CPUX clock on A33
On Wed, Dec 14, 2016 at 04:54:14AM +0800, Icenowy Zheng wrote: > > > 13.12.2016, 23:44, "Maxime Ripard" : > > On Tue, Dec 13, 2016 at 11:22:48PM +0800, Icenowy Zheng wrote: > >> The CPUX clock on A33, which is for the Cortex-A7 cores, is designed to > >> be changeable by changing the rate of PLL_CPUX. > >> > >> Add CLK_SET_RATE_PARENT flag to this clock. > >> > >> Signed-off-by: Icenowy Zheng > > > > Acked-by: Maxime Ripard > > Excuse me, have you merged this patch? Yes, sorry, that's what I meant :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] vhost: introduce O(1) vq metadata cache
On 2016年12月14日 16:14, kbuild test robot wrote: Hi Jason, [auto build test WARNING on vhost/linux-next] [also build test WARNING on v4.9 next-20161214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jason-Wang/vhost-introduce-O-1-vq-metadata-cache/20161214-160153 base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next config: i386-randconfig-x005-201650 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree Thanks, V2 will be posted soon.
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Michal Marek a écrit:
[...]
> A minimal example would be
>
> t1.c:
> struct s1;
> struct s2 {
> int i;
> }
> struct s3 {
> struct s1 *ptr1;
> struct s2 *ptr2;
> }
> void foo(struct s3*);
> EXPORT_SYMBOL(foo);
>
> t2.c:
> struct s1 {
> int j;
> }
> struct s2;
> struct s3 {
> struct s1 *ptr1;
> struct s2 *ptr2;
> }
> void foo(struct s3*);
> EXPORT_SYMBOL(foo);
>
> genksyms expands this to
> void foo ( struct s3 { struct s1 { UNKNOWN } * ptr1 ; struct s2 { int i ; } *
> ptr2 ; } * )
>
> or
>
> void foo ( struct s3 { struct s1 { int j ; } * ptr1 ; struct s2 { UNKNOWN } *
> ptr2 ; } * )
> respectively.
Thanks, I have built an independant test case from this:
$ cat t1.c
struct s1;
struct s2 {
int i;
};
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
};
void foo(struct s3*);
$ cat t2.c
struct s1 {
int j;
};
struct s2;
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
};
void foo(struct s3*);
$ gcc -g -c t1.c
$ gcc -g -c t2.c
$ abidiff t1.o t2.o
$
So, as you see here, abidiff considers t1.o and t2.o has having the same
ABI, so it considers the two foo functions to be equivalent.
> The types are the same, but their visibility in the different
> compilation units differs.
I see, for genksyms, the order of declarations matters, especially when
forward declarations are involved.
Libabigail does a "whole binary" analysis of types.
So, consider the point of use of the type 'struct s1*'. Even if 'struct
s' is just forward-declared at that point, the declaration of struct s1
is "resolved" to its definition. Even if the definition comes later in
the binary.
In other words, if struct s1 is defined in the binary, you'll never have
that "struct s1 {UNKNOWN} *ptr1;" that you see in genksyms's
representation.
Cheers,
--
Dodji
Re: [PATCH 09/18] arm64: introduce binfmt_elf32.c
On Mon, Dec 05, 2016 at 03:10:19PM +, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:08PM +0300, Yury Norov wrote:
> > As we support more than one compat formats, it looks more reasonable
> > to not use fs/compat_binfmt.c. Custom binfmt_elf32.c allows to move aarch32
> > specific definitions there and make code more maintainable and readable.
>
> Can you remind me why we need this patch (rather than using the default
> fs/compat_binfmt_elf.c which you include here anyway)?
https://patchwork.kernel.org/patch/8756121/
This is mostly to avoid runtime checks and hide some re-definitions
for aarch32 from ilp32, to avoid re-re-definition.
>
> > --- /dev/null
> > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > @@ -0,0 +1,31 @@
> > +/*
> > + * Support for AArch32 Linux ELF binaries.
> > + */
> > +
> > +/* AArch32 EABI. */
> > +#define EF_ARM_EABI_MASK 0xff00
> > +
> > +#define compat_start_threadcompat_start_thread
> > +#define COMPAT_SET_PERSONALITY(ex) \
> > +do { \
> > + clear_thread_flag(TIF_32BIT_AARCH64); \
> > + set_thread_flag(TIF_32BIT); \
> > +} while (0)
>
> You introduce this here but it seems to still be present in asm/elf.h.
Hmm... Maybe chunk that delete it from asm/elf.h was dropped at some
rebase. Thank you for the catch. I'll check it again.
Yury
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-14 10:36, Dodji Seketeli wrote:
> Michal Marek a écrit:
>
> [...]
>
>> A minimal example would be
>>
>> t1.c:
>> struct s1;
>> struct s2 {
>> int i;
>> }
>> struct s3 {
>> struct s1 *ptr1;
>> struct s2 *ptr2;
>> }
>> void foo(struct s3*);
>> EXPORT_SYMBOL(foo);
>>
>> t2.c:
>> struct s1 {
>> int j;
>> }
>> struct s2;
>> struct s3 {
>> struct s1 *ptr1;
>> struct s2 *ptr2;
>> }
>> void foo(struct s3*);
>> EXPORT_SYMBOL(foo);
>>
>> genksyms expands this to
>> void foo ( struct s3 { struct s1 { UNKNOWN } * ptr1 ; struct s2 { int i ; }
>> * ptr2 ; } * )
>>
>> or
>>
>> void foo ( struct s3 { struct s1 { int j ; } * ptr1 ; struct s2 { UNKNOWN }
>> * ptr2 ; } * )
>> respectively.
>
> Thanks, I have built an independant test case from this:
>
> $ cat t1.c
> struct s1;
> struct s2 {
> int i;
> };
> struct s3 {
> struct s1 *ptr1;
> struct s2 *ptr2;
> };
> void foo(struct s3*);
> $ cat t2.c
> struct s1 {
> int j;
> };
> struct s2;
> struct s3 {
> struct s1 *ptr1;
> struct s2 *ptr2;
> };
> void foo(struct s3*);
> $ gcc -g -c t1.c
> $ gcc -g -c t2.c
> $ abidiff t1.o t2.o
> $
>
> So, as you see here, abidiff considers t1.o and t2.o has having the same
> ABI, so it considers the two foo functions to be equivalent.
Wow. That sounds too good to be true.
>> The types are the same, but their visibility in the different
>> compilation units differs.
>
> I see, for genksyms, the order of declarations matters, especially when
> forward declarations are involved.
>
> Libabigail does a "whole binary" analysis of types.
>
> So, consider the point of use of the type 'struct s1*'. Even if 'struct
> s' is just forward-declared at that point, the declaration of struct s1
> is "resolved" to its definition. Even if the definition comes later in
> the binary.
But there isn't any definition of struct s1 in t1.o. Does abidiff
"steal" the definition from the other object file? That would be
legitimate, I'm just curious.
Thanks,
Michal
Re: [PATCH 6/7] mq-deadline: add blk-mq adaptation of the deadline IO scheduler
On 12/08/2016 09:13 PM, Jens Axboe wrote:
> +static inline bool dd_rq_is_shadow(struct request *rq)
> +{
> + return rq->rq_flags & RQF_ALLOCED;
> +}
Hello Jens,
Something minor: because req_flags_t has been defined using __bitwise
(typedef __u32 __bitwise req_flags_t) sparse complains for the above
function about converting req_flags_t into bool. How about changing the
body of that function into "return (rq->rq_flags & RQF_ALLOCED) != 0" to
keep sparse happy?
Bart.
Re: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on
On Wed, Dec 14, 2016 at 10:11:19AM +0100, Arnd Bergmann wrote: > On Wednesday, December 14, 2016 9:58:53 AM CET Geert Uytterhoeven wrote: > > > > > > --- a/drivers/char/Kconfig > > > +++ b/drivers/char/Kconfig > > > @@ -589,10 +589,13 @@ config TELCLOCK > > > controlling the behavior of this hardware. > > > > > > config DEVPORT > > > - bool > > > + bool "/dev/port character device" > > > > bool "/dev/port character device" if EXPERT? > > I think the 'default y' is good enough, there are good reasons > even for non-EXPERT configurations to turn this off. Agreed. /dev/port seems like something the majority of modern systems can safely turn off.
RE: [PATCH 3/3] secure_seq: use fast&secure siphash instead of slow&insecure md5
From: Jason A. Donenfeld
> Sent: 14 December 2016 00:17
> This gives a clear speed and security improvement. Rather than manually
> filling MD5 buffers, we simply create a layout by a simple anonymous
> struct, for which gcc generates rather efficient code.
...
> + const struct {
> + struct in6_addr saddr;
> + struct in6_addr daddr;
> + __be16 sport;
> + __be16 dport;
> + } __packed combined = {
> + .saddr = *(struct in6_addr *)saddr,
> + .daddr = *(struct in6_addr *)daddr,
> + .sport = sport,
> + .dport = dport
> + };
You need to look at the effect of marking this (and the other)
structures 'packed' on architectures like sparc64.
David
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
On 12/12/2016 10:22 PM, Heinrich Schuchardt wrote:
> On 12/12/2016 11:18 AM, Neil Armstrong wrote:
>> The Amlogic Meson GXBB secure monitor uses part of the memory space, this
>> patch adds these reserved zones and redefines the usable memory range for
>> each boards.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21
>> +
>> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi| 2 +-
>> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
>> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts| 2 +-
>> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
>> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
>> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
>> 11 files changed, 31 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> index 7a078be..ac40b2d 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> @@ -56,7 +56,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> -reg = <0x0 0x0 0x0 0x8000>;
>> +reg = <0x0 0x100 0x0 0x7f00>;
>> };
>>
>> vddio_boot: regulator-vddio_boot {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index fc033c0..e085588 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -55,6 +55,27 @@
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> +reserved-memory {
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +secos: secos {
>> +reg = <0x0 0x0530 0x0 0x200>;
>> +no-map;
>> +};
>
> Hello Neil,
>
> In
> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts
> the secos region does not exist. In linux-next I find no reference to
> the secos label. Where is the consumer of the region defined?
>
>> +
>> +pstore: pstore {
>> +reg = <0x0 0x0730 0x0 0x10>;
>> +no-map;
>> +};
>
> In
> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts
> and other files pstore uses a different position
> (reg = <0x0 0x2000 0x0 0x10>;).
> Why are we moving this?
> Should this region be marked
> compatible = "ramoops"; ?
> Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt.
>
> It would be nice if you could add a short description of each reserved
> area to the commit message.
>
> Regards
>
> Heinrich Schuchardt
>
>> +
>> +secmon: secmon {
>> +reg = <0x0 0x1000 0x0 0x20>;
>> +no-map;
>> +};
>> +};
>> +
>> cpus {
>> #address-cells = <0x2>;
>> #size-cells = <0x0>;
>
>
Hi Heinrich,
Thanks for testing and for the report,
we are still struggling into finding what are these zones and how to label them
correctly.
We need to identify the zones on all boards, the patch I provided works on a
non-odroid-c2 and gxm and gxl boards.
Neil
[GIT PULL] MMC for v.4.10 - take 2/2
Hi Linus,
Here's a second PR for MMC for v4.10.
As a matter of fact it's only one change that moves some mmc files
around. I thought it was a good idea to get this into v4.10, as it
gives us a nice and fresh base for v4.11.
Details are as usual found in the signed tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit ff6af28faff53a7389230026b83e543385f7b21d:
mmc: sdhci-cadence: add Cadence SD4HC support (2016-12-08 15:02:52 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.10-2
for you to fetch changes up to f397c8d80a5e413984bd9ccdf4161c7156b365ce:
mmc: block: Move files to core (2016-12-12 16:30:05 +0100)
MMC core:
- Move files from the card directory to the core directory to enable
future clean-ups of the generic mmc header files and interfaces.
Ulf Hansson (1):
mmc: block: Move files to core
drivers/mmc/Kconfig| 2 -
drivers/mmc/Makefile | 1 -
drivers/mmc/card/Kconfig | 70 --
drivers/mmc/card/Makefile | 10 -
drivers/mmc/core/Kconfig | 66
drivers/mmc/core/Makefile | 4 ++
drivers/mmc/{card => core}/block.c | 0
drivers/mmc/{card => core}/block.h | 0
drivers/mmc/{card => core}/mmc_test.c | 2 -
drivers/mmc/{card => core}/queue.c | 2 -
drivers/mmc/{card => core}/queue.h | 0
drivers/mmc/{card => core}/sdio_uart.c | 2 +-
12 files changed, 71 insertions(+), 88 deletions(-)
delete mode 100644 drivers/mmc/card/Kconfig
delete mode 100644 drivers/mmc/card/Makefile
rename drivers/mmc/{card => core}/block.c (100%)
rename drivers/mmc/{card => core}/block.h (100%)
rename drivers/mmc/{card => core}/mmc_test.c (99%)
rename drivers/mmc/{card => core}/queue.c (99%)
rename drivers/mmc/{card => core}/queue.h (100%)
rename drivers/mmc/{card => core}/sdio_uart.c (99%)
Re: [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
On 13/12/16 12:09, Bartosz Golaszewski wrote: > Add the vga-bridge node to the board DT together with corresponding > ports and vga connector. This allows to retrieve the edid info from > the display automatically. > > Signed-off-by: Bartosz Golaszewski > Reviewed-by: Laurent Pinchart > --- > arch/arm/boot/dts/da850-lcdk.dts | 51 > > 1 file changed, 51 insertions(+) Reviewed-by: Tomi Valkeinen Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Dodji Seketeli a écrit:
Grr, I did paste the wrong content of t1.c and t2.c in my last message sorry.
Here are the correct ones:
$ cat t1.c
struct s1;
struct s2 {
int i;
};
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
};
void foo(struct s3* s __attribute__((unused)))
{
}
$ cat t2.c
struct s1 {
int j;
};
struct s2;
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
};
void foo(struct s3* s __attribute__((unused)))
{
}
$ gcc -g -c t1.c
$ gcc -g -c t2.c
$ abidiff t1.o t2.o
$
The rest of my previous message still applies :-)
> So, as you see here, abidiff considers t1.o and t2.o has having the same
> ABI, so it considers the two foo functions to be equivalent.
>
>> The types are the same, but their visibility in the different
>> compilation units differs.
>
> I see, for genksyms, the order of declarations matters, especially when
> forward declarations are involved.
>
> Libabigail does a "whole binary" analysis of types.
>
> So, consider the point of use of the type 'struct s1*'. Even if 'struct
> s' is just forward-declared at that point, the declaration of struct s1
> is "resolved" to its definition. Even if the definition comes later in
> the binary.
>
> In other words, if struct s1 is defined in the binary, you'll never have
> that "struct s1 {UNKNOWN} *ptr1;" that you see in genksyms's
> representation.
Thanks.
--
Dodji
Re: [PATCH v4 2/4] cpuidle:powernv: Add helper function to populate powernv idle states.
Hi Balbir,
On Tue, Dec 13, 2016 at 10:51:04PM +1100, Balbir Singh wrote:
>
>
> On 10/12/16 00:32, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy"
> >
> > In the current code for powernv_add_idle_states, there is a lot of code
> > duplication while initializing an idle state in powernv_states table.
> >
> > Add an inline helper function to populate the powernv_states[] table for
> > a given idle state. Invoke this for populating the "Nap", "Fastsleep"
> > and the stop states in powernv_add_idle_states.
> >
> > Signed-off-by: Gautham R. Shenoy
> > ---
> > drivers/cpuidle/cpuidle-powernv.c | 85
> > ++-
> > include/linux/cpuidle.h | 1 +
> > 2 files changed, 50 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle-powernv.c
> > b/drivers/cpuidle/cpuidle-powernv.c
> > index 7fe442c..db18af1 100644
> > --- a/drivers/cpuidle/cpuidle-powernv.c
> > +++ b/drivers/cpuidle/cpuidle-powernv.c
> > @@ -167,6 +167,24 @@ static int powernv_cpuidle_driver_init(void)
> > return 0;
> > }
> >
> > +static inline void add_powernv_state(int index, const char *name,
> > +unsigned int flags,
> > +int (*idle_fn)(struct cpuidle_device *,
> > + struct cpuidle_driver *,
> > + int),
> > +unsigned int target_residency,
> > +unsigned int exit_latency,
> > +u64 psscr_val)
> > +{
> > + strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> > + strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
>
> Do name and desc ever diverge?
On some other architectures, like kirkwood (see
drivers/cpuidle/cpuidle-kirkwood.c) they do. "desc" field is used to
provide a more descriptive information regarding the idle state.
On POWER, the names were self-explanatory. So, we have desc same as
the name.
>
> > + powernv_states[index].flags = flags;
> > + powernv_states[index].target_residency = target_residency;
> > + powernv_states[index].exit_latency = exit_latency;
> > + powernv_states[index].enter = idle_fn;
>
> Why not call it idle_fn instead of enter?
"enter" is a field name in the generic cpuidle_state structure and
powernv_states[] is an instance of that structure.
>
> > + stop_psscr_table[index] = psscr_val;
> > +}
> > +
> > static int powernv_add_idle_states(void)
> > {
> > struct device_node *power_mgt;
> > @@ -236,6 +254,7 @@ static int powernv_add_idle_states(void)
> > "ibm,cpu-idle-state-residency-ns", residency_ns,
> > dt_idle_states);
> >
> > for (i = 0; i < dt_idle_states; i++) {
> > + unsigned int exit_latency, target_residency;
> > /*
> > * If an idle state has exit latency beyond
> > * POWERNV_THRESHOLD_LATENCY_NS then don't use it
> > @@ -243,28 +262,33 @@ static int powernv_add_idle_states(void)
> > */
> > if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
>
> Ideally this should be called POWERNV_MAX_THRESHOLD_LATENCY_NS then
Yes, it can be called that. But then again, we're only interested in
the upper threshold in this code. I will add a comment near the macro
definition.
>
> > continue;
> > + /*
> > +* Firmware passes residency and latency values in ns.
> > +* cpuidle expects it in us.
> > +*/
> > + exit_latency = ((unsigned int)latency_ns[i]) / 1000;
> > + if (!rc)
> > + target_residency = residency_ns[i] / 1000;
> > + else
> > + target_residency = 0;
>
> Where do we get rc from? what does target_residency = 0 mean?
The rc value comes from the
of_property_read_u32_array(power_mgt,
"ibm,cpu-idle-state-residency-ns", residency_ns,
dt_idle_states);
just before the for-loop. This tells us whether the firmware has
populated the residency information for the idle state or not.
rc != 0 indicates that the firmware has not populated the value.
Since the governor will pick the first idle state whose
target_residency matches the predicted residency, setting
target_residency = 0 implies that if any stop state is selected at
all, it is the earliest state.
> Balbir Singh
>
RE: [PATCH 1/3] siphash: add cryptographically secure hashtable function
From: Jason A. Donenfeld > Sent: 14 December 2016 00:17 > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > > SipHash isn't just some new trendy hash function. It's been around for a > while, and there really isn't anything that comes remotely close to > being useful in the way SipHash is. With that said, why do we need this? > > There are a variety of attacks known as "hashtable poisoning" in which an > attacker forms some data such that the hash of that data will be the > same, and then preceeds to fill up all entries of a hashbucket. This is > a realistic and well-known denial-of-service vector. > > Linux developers already seem to be aware that this is an issue, and > various places that use hash tables in, say, a network context, use a > non-cryptographically secure function (usually jhash) and then try to > twiddle with the key on a time basis (or in many cases just do nothing > and hope that nobody notices). While this is an admirable attempt at > solving the problem, it doesn't actually fix it. SipHash fixes it. > > (It fixes it in such a sound way that you could even build a stream > cipher out of SipHash that would resist the modern cryptanalysis.) > > There are a modicum of places in the kernel that are vulnerable to > hashtable poisoning attacks, either via userspace vectors or network > vectors, and there's not a reliable mechanism inside the kernel at the > moment to fix it. The first step toward fixing these issues is actually > getting a secure primitive into the kernel for developers to use. Then > we can, bit by bit, port things over to it as deemed appropriate. > > Dozens of languages are already using this internally for their hash > tables. Some of the BSDs already use this in their kernels. SipHash is > a widely known high-speed solution to a widely known problem, and it's > time we catch-up. ... > +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]) ... > + u64 k0 = get_unaligned_le64(key); > + u64 k1 = get_unaligned_le64(key + sizeof(u64)); ... > + m = get_unaligned_le64(data); All these unaligned accesses are going to get expensive on architectures like sparc64. David
Re: [PATCH v7 1/5] ARM: dts: da850: rename the display node label
On 13/12/16 12:09, Bartosz Golaszewski wrote:
> The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
> The label is also 'display', but change it to 'lcdc' to make it clear
> what the underlying hardware is.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/da850.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 104155d..6b0ef3d 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -458,7 +458,7 @@
> dma-names = "tx", "rx";
> };
>
> - display: display@213000 {
> + lcdc: display@213000 {
> compatible = "ti,da850-tilcdc";
> reg = <0x213000 0x1000>;
> interrupts = <52>;
>
Reviewed-by: Tomi Valkeinen
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH v2] arm64: mm: Fix NOMAP page initialization
On ThunderX systems with certain memory configurations we see the
following BUG_ON():
kernel BUG at mm/page_alloc.c:1848!
This happens for some configs with 64k page size enabled. The BUG_ON()
checks if start and end page of a memmap range belongs to the same
zone.
The BUG_ON() check fails if a memory zone contains NOMAP regions. In
this case the node information of those pages is not initialized. This
causes an inconsistency of the page links with wrong zone and node
information for that pages. NOMAP pages from node 1 still point to the
mem zone from node 0 and have the wrong nid assigned.
The reason for the mis-configuration is a change in pfn_valid() which
reports pages marked NOMAP as invalid:
68709f45385a arm64: only consider memblocks with NOMAP cleared for linear
mapping
This causes pages marked as nomap being no longer reassigned to the
new zone in memmap_init_zone() by calling __init_single_pfn().
Fixing this by implementing an arm64 specific early_pfn_valid(). This
causes all pages of sections with memory including NOMAP ranges to be
initialized by __init_single_page() and ensures consistency of page
links to zone, node and section.
The HAVE_ARCH_PFN_VALID config option now requires an explicit
definiton of early_pfn_valid() in the same way as pfn_valid(). This
allows a customized implementation of early_pfn_valid() which
redirects to pfn_present() for arm64.
v2:
* Use pfn_present() instead of memblock_is_memory() to support also
non-memory NOMAP holes
Signed-off-by: Robert Richter
---
arch/arm/include/asm/page.h | 1 +
arch/arm64/include/asm/page.h | 2 ++
arch/arm64/mm/init.c | 12
include/linux/mmzone.h| 5 -
4 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index 4355f0ec44d6..79761bd55f94 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -158,6 +158,7 @@ typedef struct page *pgtable_t;
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
extern int pfn_valid(unsigned long);
+#define early_pfn_valid(pfn) pfn_valid(pfn)
#endif
#include
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 8472c6def5ef..17ceb7435ded 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -49,6 +49,8 @@ typedef struct page *pgtable_t;
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
extern int pfn_valid(unsigned long);
+extern int early_pfn_valid(unsigned long);
+#define early_pfn_valid early_pfn_valid
#endif
#include
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 212c4d1e2f26..bf1f5db11428 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -145,11 +145,23 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max)
#endif /* CONFIG_NUMA */
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
+
int pfn_valid(unsigned long pfn)
{
return memblock_is_map_memory(pfn << PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);
+
+/*
+ * We use pfn_present() here to make sure all pages of a section
+ * including NOMAP pages are initialized with __init_single_page().
+ */
+int early_pfn_valid(unsigned long pfn)
+{
+ return pfn_present(pfn);
+}
+EXPORT_SYMBOL(early_pfn_valid);
+
#endif
#ifndef CONFIG_SPARSEMEM
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0f088f3a2fed..bedcf8a95881 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1170,12 +1170,16 @@ static inline struct mem_section
*__pfn_to_section(unsigned long pfn)
}
#ifndef CONFIG_HAVE_ARCH_PFN_VALID
+
static inline int pfn_valid(unsigned long pfn)
{
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
}
+
+#define early_pfn_valid(pfn) pfn_valid(pfn)
+
#endif
static inline int pfn_present(unsigned long pfn)
@@ -1200,7 +1204,6 @@ static inline int pfn_present(unsigned long pfn)
#define pfn_to_nid(pfn)(0)
#endif
-#define early_pfn_valid(pfn) pfn_valid(pfn)
void sparse_init(void);
#else
#define sparse_init() do {} while (0)
--
2.1.4
[PATCH v2 0/2] iio: adc: hx711: Add IIO driver for AVIA HX711 ADC
This series adds IIO driver support for the AVIA HX711 ADC which is mostly used in weighting cells. The first patch adds the new DT binding for which a new vendor avia was also added. The second patch is the simple IIO driver implemented as ADC. The protocol is specific to this device and implemented using GPIO's. Documentation of the chip can be found here: https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf Changes: Lots of updates thanks to Peters review. * Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711" - typo - removed unneded section * Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711" - updated help text in Kconfig - removed dead code - removed unused power management - reduced channel spec to what is actually used - added error handling in case reset of chip not possible Andreas Klinger (2): iio: adc: hx711: Add DT binding for avia,hx711 iio: adc: hx711: Add IIO driver for AVIA HX711 .../devicetree/bindings/iio/adc/avia-hx711.txt | 21 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/adc/Kconfig| 18 ++ drivers/iio/adc/Makefile | 1 + drivers/iio/adc/hx711.c| 231 + 5 files changed, 272 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt create mode 100644 drivers/iio/adc/hx711.c -- 2.1.4
Re: [PATCH] drm/bridge: analogix_dp: set the DPCD600 during disabling the psr
On Wed, Dec 14, 2016 at 12:03 AM, Archit Taneja wrote:
> Hi,
>
> On 12/12/2016 08:28 PM, Sean Paul wrote:
>>
>> On Fri, Dec 9, 2016 at 9:49 PM, Caesar Wang wrote:
>>>
>>> Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host
>>> device, that will cause the panel hang on the startup display.
>>> The root cause we use the fast link mode during enter and exit the psr,
>>> this issue is gone if switching the fast link to main link mode.
>>>
>>
>> Cc: Archit Taneja
>
>
> Do we want this as a fix in 4.10? Or is it okay to get it in 4.11?
> In other words, should this go to drm-misc-next or drm-misc-fixes?
>
Hi Archit,
4.11 is totally fine.
Sean
> Thanks,
> Archit
>
>
>>
>>> Signed-off-by: Caesar Wang
>>> ---
>>>
>>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index 6e0447f..6a5347b 100644
>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -133,6 +133,7 @@ int analogix_dp_disable_psr(struct device *dev)
>>> {
>>> struct analogix_dp_device *dp = dev_get_drvdata(dev);
>>> struct edp_vsc_psr psr_vsc;
>>> + int ret;
>>>
>>> if (!dp->psr_support)
>>> return -EINVAL;
>>> @@ -147,6 +148,10 @@ int analogix_dp_disable_psr(struct device *dev)
>>> psr_vsc.DB0 = 0;
>>> psr_vsc.DB1 = 0;
>>>
>>> + ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER,
>>> DP_SET_POWER_D0);
>>> + if (ret != 1)
>>> + dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
>>> +
>>> analogix_dp_send_psr_spd(dp, &psr_vsc);
>>> return 0;
>>> }
>>> --
>>> 2.7.4
>>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
[PATCH v2 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
cells.
The protocol is quite simple and using GPIO's:
One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
The raw value read from the chip is delivered.
To get a weight one needs to subtract the zero offset and scale it.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/Kconfig | 18
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 231 +++
3 files changed, 250 insertions(+)
create mode 100644 drivers/iio/adc/hx711.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 932de1f9d1e7..918f582288c9 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -205,6 +205,24 @@ config HI8435
This driver can also be built as a module. If so, the module will be
called hi8435.
+config HX711
+ tristate "AVIA HX711 ADC for weight cells"
+ depends on GPIOLIB
+ help
+ If you say yes here you get support for AVIA HX711 ADC which is used
+ for weight cells
+
+ This driver uses two GPIOs, one for setting the clock and the other
+ one for getting the data
+
+ Currently the raw value is read from the chip and delivered.
+ For getting an actual weight one needs to subtract the
+ zero offset and multiply by a scale factor.
+ This should be done in userspace.
+
+ This driver can also be built as a module. If so, the module will be
+ called hx711.
+
config INA2XX_ADC
tristate "Texas Instruments INA2xx Power Monitors IIO driver"
depends on I2C && !SENSORS_INA2XX
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index b1aa456e6af3..d46e289900ef 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_HX711) += hx711.o
obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
new file mode 100644
index ..420f9451f3d1
--- /dev/null
+++ b/drivers/iio/adc/hx711.c
@@ -0,0 +1,231 @@
+/*
+ * HX711: analog to digital converter for weight sensor module
+ *
+ * Copyright (c) 2016 Andreas Klinger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HX711_GAIN_32 2 /* gain = 32 for channel B */
+#define HX711_GAIN_64 3 /* gain = 64 for channel A */
+#define HX711_GAIN_128 1 /* gain = 128 for channel A */
+
+struct hx711_data {
+ struct device *dev;
+ struct gpio_desc*gpiod_sck;
+ struct gpio_desc*gpiod_dout;
+ int gain_pulse;
+ struct mutexlock;
+};
+
+static int hx711_reset(struct hx711_data *hx711_data)
+{
+ int i, val;
+
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (val) {
+ gpiod_set_value(hx711_data->gpiod_sck, 1);
+ udelay(80);
+ gpiod_set_value(hx711_data->gpiod_sck, 0);
+
+ for (i = 0; i < 1000; i++) {
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (!val)
+ break;
+ /* sleep at least 1 ms */
+ msleep(1);
+ }
+ }
+
+ return val;
+}
+
+static int hx711_cycle(struct hx711_data *hx711_data)
+{
+ int val;
+
+ /* if preempted for more then 60us while SCK is high:
+* hx711 is going in reset
+* ==> measuring is false
+*/
+ preempt_disable();
+ gpiod_set_value(hx711_data->gpiod_sck, 1);
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ gpiod_set_value(hx711_data->gpiod_sck, 0);
+ preempt_enable();
+
+ return val;
+}
+
+static int hx711_read(struct hx711_data *hx711_data)
+{
+ int i, ret;
+ int value = 0;
+
+ if (hx711_reset(hx711_data)) {
+ dev_err(hx711_data->dev, "reset failed!");
+ return -1;
+ }
+
+ for (i = 0; i < 24; i++) {
+ value <<= 1;
+
[PATCH v2 1/2] iio: adc: hx711: Add DT binding for avia,hx711
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger
---
.../devicetree/bindings/iio/adc/avia-hx711.txt | 21 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
new file mode 100644
index ..6a4659fc7a4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,21 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+
+Recommended properties:
+ - gain: Gain select, can be 32, 64 or 128
+ default is 128
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ gain = <32>
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 44ddc980b085..4696bb5c2198 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -32,6 +32,7 @@ atlas Atlas Scientific LLC
atmel Atmel Corporation
auoAU Optronics Corporation
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
boeBOE Technology Group Co., Ltd.
--
2.1.4
Re: [PATCH] arm64: mm: Fix NOMAP page initialization
On 12.12.16 17:53:02, Yisheng Xie wrote:
> It seems that memblock_is_memory() is also too strict for early_pfn_valid,
> so what about this patch, which use common pfn_valid as early_pfn_valid
> when CONFIG_HAVE_ARCH_PFN_VALID=y:
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0f088f3..9d596f3 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1200,7 +1200,17 @@ static inline int pfn_present(unsigned long pfn)
> #define pfn_to_nid(pfn)(0)
> #endif
>
> +#ifdef CONFIG_HAVE_ARCH_PFN_VALID
> +static inline int early_pfn_valid(unsigned long pfn)
> +{
> + if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> + return 0;
> + return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
> +}
I sent a V2 patch that uses pfn_present(). This only initilizes
sections with memory.
-Robert
> +#define early_pfn_valid early_pfn_valid
> +#else
> #define early_pfn_valid(pfn) pfn_valid(pfn)
> +#endif
> void sparse_init(void);
> #else
> #define sparse_init() do {} while (0)
>
>
>
[PATCH V2] vhost: introduce O(1) vq metadata cache
When device IOTLB is enabled, all address translations were stored in
interval tree. O(lgN) searching time could be slow for virtqueue
metadata (avail, used and descriptors) since they were accessed much
often than other addresses. So this patch introduces an O(1) array
which points to the interval tree nodes that store the translations of
vq metadata. Those array were update during vq IOTLB prefetching and
were reset during each invalidation and tlb update. Each time we want
to access vq metadata, this small array were queried before interval
tree. This would be sufficient for static mappings but not dynamic
mappings, we could do optimizations on top.
Test were done with l2fwd in guest (2M hugepage):
noiommu | before| after
tx 1.32Mpps | 1.06Mpps(82%) | 1.30Mpps(98%)
rx 2.33Mpps | 1.46Mpps(63%) | 2.29Mpps(98%)
We can almost reach the same performance as noiommu mode.
Signed-off-by: Jason Wang
---
Changes from V1:
- silent 32bit build warning
---
drivers/vhost/vhost.c | 136 --
drivers/vhost/vhost.h | 8 +++
2 files changed, 118 insertions(+), 26 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c6f2d89..50ed625 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -282,6 +282,22 @@ void vhost_poll_queue(struct vhost_poll *poll)
}
EXPORT_SYMBOL_GPL(vhost_poll_queue);
+static void __vhost_vq_meta_reset(struct vhost_virtqueue *vq)
+{
+ int j;
+
+ for (j = 0; j < VHOST_NUM_ADDRS; j++)
+ vq->meta_iotlb[j] = NULL;
+}
+
+static void vhost_vq_meta_reset(struct vhost_dev *d)
+{
+ int i;
+
+ for (i = 0; i < d->nvqs; ++i)
+ __vhost_vq_meta_reset(d->vqs[i]);
+}
+
static void vhost_vq_reset(struct vhost_dev *dev,
struct vhost_virtqueue *vq)
{
@@ -311,6 +327,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->busyloop_timeout = 0;
vq->umem = NULL;
vq->iotlb = NULL;
+ __vhost_vq_meta_reset(vq);
}
static int vhost_worker(void *data)
@@ -690,6 +707,18 @@ static int vq_memory_access_ok(void __user *log_base,
struct vhost_umem *umem,
return 1;
}
+static inline void __user *vhost_vq_meta_fetch(struct vhost_virtqueue *vq,
+ u64 addr, unsigned int size,
+ int type)
+{
+ const struct vhost_umem_node *node = vq->meta_iotlb[type];
+
+ if (!node)
+ return NULL;
+
+ return (void *)(uintptr_t)(node->userspace_addr + addr - node->start);
+}
+
/* Can we switch to this memory table? */
/* Caller should have device mutex but not vq mutex */
static int memory_access_ok(struct vhost_dev *d, struct vhost_umem *umem,
@@ -732,8 +761,14 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq,
void *to,
* could be access through iotlb. So -EAGAIN should
* not happen in this case.
*/
- /* TODO: more fast path */
struct iov_iter t;
+ void __user *uaddr = vhost_vq_meta_fetch(vq,
+(u64)(uintptr_t)to, size,
+VHOST_ADDR_DESC);
+
+ if (uaddr)
+ return __copy_to_user(uaddr, from, size);
+
ret = translate_desc(vq, (u64)(uintptr_t)to, size,
vq->iotlb_iov,
ARRAY_SIZE(vq->iotlb_iov),
VHOST_ACCESS_WO);
@@ -761,8 +796,14 @@ static int vhost_copy_from_user(struct vhost_virtqueue
*vq, void *to,
* could be access through iotlb. So -EAGAIN should
* not happen in this case.
*/
- /* TODO: more fast path */
+ void __user *uaddr = vhost_vq_meta_fetch(vq,
+(u64)(uintptr_t)from, size,
+VHOST_ADDR_DESC);
struct iov_iter f;
+
+ if (uaddr)
+ return __copy_from_user(to, uaddr, size);
+
ret = translate_desc(vq, (u64)(uintptr_t)from, size,
vq->iotlb_iov,
ARRAY_SIZE(vq->iotlb_iov),
VHOST_ACCESS_RO);
@@ -782,17 +823,12 @@ static int vhost_copy_from_user(struct vhost_virtqueue
*vq, void *to,
return ret;
}
-static void __user *__vhost_get_user(struct vhost_virtqueue *vq,
-void *addr, unsigned size)
+static void __user *__vhost_get_user_slow(struct vhost_virtqueue *vq,
+ void *addr, unsigned int size,
+ int type)
{
int ret;
- /* This function should be called after iotlb
-* prefetch, which means we're sure that vq
-* could be access through iotlb. So -EAGAIN should
-
Re: sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport
On Wed, Dec 14, 2016 at 5:37 AM, Marcelo Ricardo Leitner
wrote:
> On Tue, Dec 13, 2016 at 07:07:01PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> I am getting the following reports while running syzkaller fuzzer:
>>
>> [ INFO: suspicious RCU usage. ]
>> 4.9.0+ #85 Not tainted
>> ---
>> ./include/linux/rhashtable.h:572 suspicious rcu_dereference_check() usage!
>>
>> other info that might help us debug this:
>>
>> rcu_scheduler_active = 1, debug_locks = 0
>> 1 lock held by syz-executor1/18023:
>> #0: (sk_lock-AF_INET){+.+.+.}, at: [< inline >] lock_sock
>> include/net/sock.h:1454
>> #0: (sk_lock-AF_INET){+.+.+.}, at: []
>> sctp_getsockopt+0x45f/0x6800 net/sctp/socket.c:6432
>>
>> stack backtrace:
>> CPU: 2 PID: 18023 Comm: syz-executor1 Not tainted 4.9.0+ #85
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
>> [] lockdep_rcu_suspicious+0x139/0x180
>> kernel/locking/lockdep.c:4448
>> [< inline >] __rhashtable_lookup ./include/linux/rhashtable.h:572
>> [< inline >] rhltable_lookup ./include/linux/rhashtable.h:660
>> [] sctp_epaddr_lookup_transport+0x641/0x930
>> net/sctp/input.c:946
>
> I think this was introduced in the rhlist converstion. We had removed
> some rcu_read_lock() calls on sctp stack because rhashtable was already
> calling it, but then we didn't add them back when moving to rhlist.
>
> This code:
> +/* return a transport without holding it, as it's only used under sock lock
> */
> struct sctp_transport *sctp_epaddr_lookup_transport(
> const struct sctp_endpoint *ep,
> const union sctp_addr *paddr)
> {
> struct net *net = sock_net(ep->base.sk);
> + struct rhlist_head *tmp, *list;
> + struct sctp_transport *t;
> struct sctp_hash_cmp_arg arg = {
> - .ep= ep,
> .paddr = paddr,
> .net = net,
> + .lport = htons(ep->base.bind_addr.port),
> };
>
> - return rhashtable_lookup_fast(&sctp_transport_hashtable, &arg,
> - sctp_hash_params);
> + list = rhltable_lookup(&sctp_transport_hashtable, &arg,
> + sctp_hash_params);
>
> Had an implicit rcu_read_lock() on rhashtable_lookup_fast, but it
> doesn't on rhltable_lookup and rhltable_lookup uses _rcu calls which
> assumes we have rcu read protection.
You're right, we need to call rcu_read_lock before using rhltable_lookup.
will post a fix for it, thanks.
[RFC PATCH net-next v4 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
This patch does the following:
- Enable HW time stamp for the following platforms: SAMA5D2, SAMA5D3 and
SAMA5D4.
- HW time stamp capabilities are advertised via ethtool and macb ioctl is
updated accordingly.
- HW time stamp on the PTP Ethernet packets are received using the
SO_TIMESTAMPING API. Where timers are obtained from the PTP event/peer
registers.
Note: Patch on net-next, on December 7th.
Signed-off-by: Andrei Pistirica
---
Patch history:
Version 1:
Integration with SAMA5D2 only. This feature wasn't tested on any
other platform that might use cadence/gem.
Patch is not completely ported to the very latest version of net-next,
and it will be after review.
Version 2 modifications:
- add PTP caps for SAMA5D2/3/4 platforms
- and cosmetic changes
Version 3 modifications:
- add support for sama5D2/3/4 platforms using GEM-PTP interface.
Version 4 modifications:
- time stamp only PTP_V2 events
- maximum adjustment value is set based on Richard's input
Note: Patch on net-next, on December 14th.
drivers/net/ethernet/cadence/macb.c | 168 ++--
1 file changed, 163 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 538544a..8d5c976 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -714,6 +714,8 @@ static void macb_tx_interrupt(struct macb_queue *queue)
/* First, update TX stats if needed */
if (skb) {
+ gem_ptp_do_txstamp(bp, skb);
+
netdev_vdbg(bp->dev, "skb %u (data %p) TX
complete\n",
macb_tx_ring_wrap(bp, tail),
skb->data);
@@ -878,6 +880,8 @@ static int gem_rx(struct macb *bp, int budget)
GEM_BFEXT(RX_CSUM, ctrl) & GEM_RX_CSUM_CHECKED_MASK)
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ gem_ptp_do_rxstamp(bp, skb);
+
bp->stats.rx_packets++;
bp->stats.rx_bytes += skb->len;
@@ -2080,6 +2084,9 @@ static int macb_open(struct net_device *dev)
netif_tx_start_all_queues(dev);
+ if (bp->ptp_info)
+ bp->ptp_info->ptp_init(dev);
+
return 0;
}
@@ -2101,6 +2108,9 @@ static int macb_close(struct net_device *dev)
macb_free_consistent(bp);
+ if (bp->ptp_info)
+ bp->ptp_info->ptp_remove(dev);
+
return 0;
}
@@ -2374,6 +2384,133 @@ static int macb_set_ringparam(struct net_device *netdev,
return 0;
}
+#ifdef CONFIG_MACB_USE_HWSTAMP
+static unsigned int gem_get_tsu_rate(struct macb *bp)
+{
+ /* Note: TSU rate is hardwired to PCLK. */
+ return clk_get_rate(bp->pclk);
+}
+
+static s32 gem_get_ptp_max_adj(void)
+{
+ return 3921508;
+}
+
+static int gem_get_ts_info(struct net_device *dev,
+ struct ethtool_ts_info *info)
+{
+ struct macb *bp = netdev_priv(dev);
+
+ ethtool_op_get_ts_info(dev, info);
+ info->so_timestamping =
+ SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
+ SOF_TIMESTAMPING_SOFTWARE |
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_RAW_HARDWARE;
+ info->phc_index = -1;
+
+ if (bp->ptp_clock)
+ info->phc_index = ptp_clock_index(bp->ptp_clock);
+
+ return 0;
+}
+
+static int gem_set_hwtst(struct net_device *netdev,
+struct ifreq *ifr, int cmd)
+{
+ struct hwtstamp_config config;
+ struct macb *priv = netdev_priv(netdev);
+ u32 regval;
+
+ netdev_vdbg(netdev, "macb_hwtstamp_ioctl\n");
+
+ if (copy_from_user(&config, ifr->ifr_data, sizeof(config)))
+ return -EFAULT;
+
+ /* reserved for future extensions */
+ if (config.flags)
+ return -EINVAL;
+
+ switch (config.tx_type) {
+ case HWTSTAMP_TX_OFF:
+ priv->hwts_tx_en = false;
+ break;
+ case HWTSTAMP_TX_ON:
+ priv->hwts_tx_en = true;
+ break;
+ default:
+ return -ERANGE;
+ }
+
+ switch (config.rx_filter) {
+ case HWTSTAMP_FILTER_NONE:
+ if (priv->hwts_rx_en)
+ priv->hwts_rx_en = false;
+ break;
+ case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ config.rx_filter = HWTSTAMP_FILT
[GIT PULL] trivial for 4.10
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git for-linus to receive 4.10 merge window updates from trivial tree I hereby confess to having rebased the for-next branch, because I wanted to drop all the '\n' additions that were obsoleted by the recent printk / pr_cont changes, and didn't want to pollute the history with unnecessary commit+revert for such a triviality; as a consequence, you're getting different commit hashes for the 5 commits compared to what's in linux-next; I believe it's fine for such a insignificant tree / commits. Thanks. Aaron Sierra (1): NTB: correct ntb_spad_count comment typo Colin Ian King (1): misc: ibmasm: fix typo in error message Masanari Iida (1): treewide: Fix printk() message errors Michael Witten (1): Documentation/device-mapper: s/getsize/getsz/ Paul Bolle (2): Remove last traces of ikconfig.h Remove references to dead make variable LINUX_INCLUDE Documentation/device-mapper/delay.txt | 4 ++-- Documentation/device-mapper/dm-crypt.txt| 2 +- Documentation/device-mapper/linear.txt | 8 Documentation/device-mapper/striped.txt | 4 ++-- Documentation/device-mapper/switch.txt | 2 +- Documentation/dontdiff | 1 - arch/arm64/kernel/hibernate.c | 4 ++-- arch/mips/kernel/asm-offsets.c | 2 +- arch/s390/boot/compressed/Makefile | 2 +- arch/sh/kernel/cpu/Makefile | 2 +- arch/sh/kernel/cpu/irq/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 2 +- drivers/acpi/Kconfig| 2 +- drivers/firmware/efi/libstub/Makefile | 2 +- drivers/isdn/hisax/q931.c | 2 +- drivers/media/usb/dvb-usb-v2/af9015.c | 2 +- drivers/mfd/max77620.c | 2 +- drivers/misc/ibmasm/module.c| 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +- drivers/net/ethernet/qlogic/qed/qed_int.c | 4 ++-- drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 2 +- drivers/net/wireless/ath/ath10k/pci.c | 2 +- drivers/net/wireless/ath/wil6210/txrx.c | 2 +- drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.c | 2 +- drivers/scsi/aic7xxx/aicasm/aicasm.c| 2 +- drivers/usb/dwc3/gadget.c | 2 +- include/linux/ntb.h | 2 +- kernel/Makefile | 2 -- scripts/gcc-plugins/latent_entropy_plugin.c | 2 +- scripts/gcc-plugins/sancov_plugin.c | 2 +- tools/power/acpi/tools/ec/ec_access.c | 2 +- 31 files changed, 36 insertions(+), 39 deletions(-) -- Jiri Kosina SUSE Labs
[GIT PULL] HID for 4.10
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus to receive 4.10 merge window updates for HID subsystem, namely = - support for new Wacom "MobileStudio Pro" class of tablets from Jason Gerecke - Microsoft Surface 3 support from Benjamin Tissoires and Microsoft Surface 4 support from Daniel Keller - uDraw PS3 tablet support from Bastien Nocera - timeout scheduling fixes for intel-ish-hid from Even Xu - HID_QUIRK_MULTI_INPUT in order to simplify LED handling from Benjamin Tissoires - support for Sony DS4 dongle and various other fixes to Sony driver from Roderick Colenbrander - other assorted smaller fixes and device ID additions = Thanks. Bastien Nocera (1): HID: udraw-ps3: Add support for the uDraw tablet for PS3 Benjamin Tissoires (9): HID: sensor-hub add quirk for Microsoft Surface 3 HID: sensor-hub: add quirk for Microchip MM7150 HID: multitouch: handle external buttons for Precision Touchpads HID: input: rework HID_QUIRK_MULTI_INPUT HID: multitouch: enable the Surface 3 Type Cover to report multitouch data HID: multitouch: do not retrieve all reports for all devices HID: i2c-hid: force the IRQ level trigger only when not set HID: cp2112: add IRQ chip handling HID: fix missing irq field Brendan McGrath (1): HID: asus: Add i2c touchpad support Dan Carpenter (1): HID: wacom: Don't clear bits unintentionally Daniel Keller (1): HID: microsoft: Add Surface 4 type cover pro 4 not JP versions David Arcari (2): Revert "HID: i2c-hid: Add support for ACPI GPIO interrupts" HID: i2c-hid: exit if the IRQ is not valid Even Xu (3): HID: intel-ish-hid: ipc: remove unused macro HID: intel-ish-hid: ipc: change timed_wait_for_timeout() to be a function HID: intel-ish-hid: ipc: use msleep_interrupt() for wait HungNien Chen (1): HID: i2c-hid: add a simple quirk to fix device defects Jason Gerecke (19): HID: wacom: Update vendor-defined usage names to better match standards HID: wacom: Have WACOM_PEN_FIELD and WACOM_FINGER_FIELD recgonize more fields HID: wacom: Refactor button-to-key translation into function HID: wacom: Detect and correct descriptors missing HID_DG_BARRELSWITCH2 HID: wacom: generic: Strip off excessive name prefixing HID: wacom: generic: Add support for height, tilt, and twist usages HID: wacom: generic: Support and use 'Custom HID' mode and usages HID: wacom: generic: Add support for vendor-defined "Distance" usage HID: wacom: generic: Add support for vendor-defined "Fingerwheel" usage HID: wacom: generic: Add support for vendor-defined "Sense" usage HID: wacom: Read and internally use corrected Intuos tool IDs HID: wacom: generic: Support tool ID and additional tool types HID: wacom: Fix sensor outbounds and redefine as offsets from each edge HID: wacom: generic: Add support for sensor offsets HID: wacom: generic: Introduce pad support HID: wacom: generic: Add support for battery status on pen and pad interfaces HID: wacom: generic: Extend pad support HID: input: Recognize ABS_WHEEL in hidinput_calc_abs_res HID: wacom: Declare tool ID 0x84a as an Intuos eraser Jiri Kosina (4): HID: intel-ish-hid: initialize ts_format.reserved HID: udraw-ps3: accel_limits is local to the driver HID: cp2112: explicitly require irqchip support in gpiolib HID: i2c-hid: fix build João Paulo Rechi Vita (1): HID: i2c-hid: Disable IRQ before freeing buffers Marcel Hasler (2): HID: usbhid: Add quirks for Mayflash/Dragonrise GameCube and PS3 adapters HID: Add new force feedback driver for Mayflash game controller adapters Pan Bian (1): HID: usbhid: fix improper return value Ping Cheng (4): HID: wacom: generic: Don't return a value for wacom_wac_event HID: wacom: generic: Send data only when the interface is defined HID: wacom: generic: Pad supports more than buttons HID: wacom: generic: Don't sync input on empty input packets Rasmus Villemoes (1): HID: intel_ish-hid: use %pUL for uuid formatting Roderick Colenbrander (11): HID: sony: Fix race condition in sony_probe HID: sony: Adjust HID report size name definitions HID: sony: Perform CRC check on bluetooth input packets HID: sony: Send ds4 output reports on output end-point HID: sony: Handle multiple touch events input record HID: sony: Adjust value range for motion sensors HID: sony: Update device ids HID: sony: Fix memory issue when connecting device using both Bluetooth and USB HID: sony: Make the DS4 touchpad a separate device HID: sony: Comply to Linux gamepad spec for DS4 HID: sony: Support DS4 dongle Srinivas Pandruvada (1): HID: intel-ish-hid: Fix
[RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
Cadence GEM provides a 102 bit time counter with 48 bits for seconds, 30 bits for nsecs and 24 bits for sub-nsecs to control 1588 timestamping. This patch does the following: - Registers to ptp clock framework - Timer initialization is done by writing time of day to the timer counter. - ns increment register is programmed as NSEC_PER_SEC/tsu-clock-rate. For a 16 bit subns precision, the subns increment equals remainder of (NS_PER_SEC/TSU_CLK) * (2^16). - Timestamps are obtained from the TX/RX PTP event/PEER registers. The timestamp obtained thus is updated in skb for upper layers to access. - The drivers register functions with ptp to perform time and frequency adjustment. - Time adjustment is done by writing to the 1558_ADJUST register. The controller will read the delta in this register and update the timer counter register. Alternatively, for large time offset adjustments, the driver reads the secs and nsecs counter values, adds/subtracts the delta and updates the timer counter. - Frequency is adjusted by adjusting addend (8bit nanosecond increment) and addendsub (16bit increment nanosecond fractions). The 102bit counter is incremented at nominal frequency with addend and addendsub values. Each period addend and addendsub values are adjusted based on ppm drift. Signed-off-by: Andrei Pistirica Signed-off-by: Harini Katakam --- Patch history: Version 1: This patch is based on original Harini's patch, implemented in a separate file to ease the review/maintanance and integration with other platforms (e.g. Zynq Ultrascale+ MPSoC). Feature was tested on SAMA5D2 platform using ptp4l v1.6 from linuxptp project and also with ptpd2 version 2.3.1. PTP was tested over IPv4,IPv6 and 802.3 protocols. In case that macb is compiled as a module, it has been renamed to cadence-macb.ko to avoid naming confusion in Makefile. Version 2 modifications: - bitfields for TSU are named according to SAMA5D2 data sheet - identify GEM-PTP support based on platform capability - add spinlock for TSU access - change macb_ptp_adjfreq and use fewer 64bit divisions Version 3 modifications: - new adjfine api with one 64 division for frequency adjustment (based on Richard's input) - add maximum adjustment frequency (ppb) based on nominal frequency - per platform PTP configuration - cosmetic changes Note 1: Kbuild uses "select" instead of "imply", and the macb maintainer agreed to make the change when it will be available in net-next. Version 4 modifications: - update adjfine for a better approximation - add maximum adjustment frequency callback to PTP platform configuraion Note 1: This driver does not support GEM-GXL! Note 2: Patch on net-next, on December 14th. drivers/net/ethernet/cadence/Kconfig| 10 +- drivers/net/ethernet/cadence/Makefile | 8 +- drivers/net/ethernet/cadence/macb.h | 118 ++ drivers/net/ethernet/cadence/macb_ptp.c | 366 4 files changed, 500 insertions(+), 2 deletions(-) create mode 100644 drivers/net/ethernet/cadence/macb_ptp.c diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig index f0bcb15..ebbc65f 100644 --- a/drivers/net/ethernet/cadence/Kconfig +++ b/drivers/net/ethernet/cadence/Kconfig @@ -29,6 +29,14 @@ config MACB support for the MACB/GEM chip. To compile this driver as a module, choose M here: the module - will be called macb. + will be called cadence-macb. + +config MACB_USE_HWSTAMP + bool "Use IEEE 1588 hwstamp" + depends on MACB + default y + select PTP_1588_CLOCK + ---help--- + Enable IEEE 1588 Precision Time Protocol (PTP) support for MACB. endif # NET_CADENCE diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile index 91f79b1..4402d42 100644 --- a/drivers/net/ethernet/cadence/Makefile +++ b/drivers/net/ethernet/cadence/Makefile @@ -2,4 +2,10 @@ # Makefile for the Atmel network device drivers. # -obj-$(CONFIG_MACB) += macb.o +cadence-macb-y := macb.o + +ifeq ($(CONFIG_MACB_USE_HWSTAMP),y) +cadence-macb-y += macb_ptp.o +endif + +obj-$(CONFIG_MACB) += cadence-macb.o diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h index d67adad..e65e985 100644 --- a/drivers/net/ethernet/cadence/macb.h +++ b/drivers/net/ethernet/cadence/macb.h @@ -10,6 +10,9 @@ #ifndef _MACB_H #define _MACB_H +#include +#include + #define MACB_GREGS_NBR 16 #define MACB_GREGS_VERSION 2 #define MACB_MAX_QUEUES 8 @@ -131,6 +134,20 @@ #define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */ #define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */ #define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */ +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */ +#define GEM_TSH0x01c0 /* 1588 Timer Seconds High */ +#define GEM_TSL
[GIT PULL] livepatching for 4.10
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus to receive 4.10 merge window updates for livepatching tree; this is just a small documentation update (as the work on the hybrid model is still underway). Thanks. Petr Mladek (1): Documentation/livepatch: Fix stale link to gmame Documentation/livepatch/livepatch.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Jiri Kosina SUSE Labs
[PATCH] ubifs: Initialize fstr_real_len
While fstr_real_len is only being used under if (encrypted),
gcc-6 still warns.
Fixes this false positive:
fs/ubifs/dir.c: In function 'ubifs_readdir':
fs/ubifs/dir.c:629:13: warning: 'fstr_real_len' may be used
uninitialized in this function [-Wmaybe-uninitialized]
fstr.len = fstr_real_len
Initialize fstr_real_len to make gcc happy.
Reported-by: Stephen Rothwell
Signed-off-by: Richard Weinberger
---
fs/ubifs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 7f01f3d2ac3b..1c5331ac9614 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -528,7 +528,7 @@ static unsigned int vfs_dent_type(uint8_t type)
*/
static int ubifs_readdir(struct file *file, struct dir_context *ctx)
{
- int fstr_real_len, err = 0;
+ int fstr_real_len = 0, err = 0;
struct fscrypt_name nm;
struct fscrypt_str fstr = {0};
union ubifs_key key;
--
2.10.2
[PATCH 2/3] clk: rockchip: rk3399: export 480M_SRC clocks id for usbphy0/usbphy1
This patch exports USBPHYx_480M_SRC clocks for usbphy.
Signed-off-by: Xing Zheng
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index 3490887..cf2af4c 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -411,9 +411,9 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
GATE(SCLK_USB2PHY1_REF, "clk_usb2phy1_ref", "xin24m", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(6), 6, GFLAGS),
- GATE(0, "clk_usbphy0_480m_src", "clk_usbphy0_480m", 0,
+ GATE(SCLK_USBPHY0_480M_SRC, "clk_usbphy0_480m_src", "clk_usbphy0_480m",
0,
RK3399_CLKGATE_CON(13), 12, GFLAGS),
- GATE(0, "clk_usbphy1_480m_src", "clk_usbphy1_480m", 0,
+ GATE(SCLK_USBPHY1_480M_SRC, "clk_usbphy1_480m_src", "clk_usbphy1_480m",
0,
RK3399_CLKGATE_CON(13), 12, GFLAGS),
MUX(0, "clk_usbphy_480m", mux_usbphy_480m_p, 0,
RK3399_CLKSEL_CON(14), 6, 1, MFLAGS),
--
2.7.4
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Michal Marek a écrit: >> Libabigail does a "whole binary" analysis of types. >> >> So, consider the point of use of the type 'struct s1*'. Even if 'struct >> s' is just forward-declared at that point, the declaration of struct s1 >> is "resolved" to its definition. Even if the definition comes later in >> the binary. > > But there isn't any definition of struct s1 in t1.o. Does abidiff > "steal" the definition from the other object file? That would be > legitimate, I'm just curious. If there is another translation unit in the *same* binary that defines struct s1, then yes, it's "stolen", as you say. But if in the entire binary, struct s1 is just declared (not defined), then it'll compare equal to any struct s1 that is defined in the *second* binary. Cheers, -- Dodji
[PATCH 1/3] clk: rockchip: rk3399: add USBPHYx_480M_SRC clock IDs
This patch add two clock IDs for the usb phy 480m source clocks. Signed-off-by: Xing Zheng --- include/dt-bindings/clock/rk3399-cru.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h index 220a60f..224daf7 100644 --- a/include/dt-bindings/clock/rk3399-cru.h +++ b/include/dt-bindings/clock/rk3399-cru.h @@ -132,6 +132,8 @@ #define SCLK_RMII_SRC 166 #define SCLK_PCIEPHY_REF100M 167 #define SCLK_DDRC 168 +#define SCLK_USBPHY0_480M_SRC 169 +#define SCLK_USBPHY1_480M_SRC 170 #define DCLK_VOP0 180 #define DCLK_VOP1 181 -- 2.7.4
[patch v1 1/1] platform/x86: mlx-platform: mlxcpld-hotplug driver style fixes
The patch contains several styling fixes:
- Make names of hotplug devices shorter;
- Change register offset assignment to defines;
- Add defines for the all event masks;
- Use PLATFORM_DEVID_NONE instead of -1;
Signed-off-by: Vadim Pasternak
---
drivers/platform/x86/mlx-platform.c | 84 ++---
1 file changed, 50 insertions(+), 34 deletions(-)
diff --git a/drivers/platform/x86/mlx-platform.c
b/drivers/platform/x86/mlx-platform.c
index 97b4c3a..04e1f2b 100644
--- a/drivers/platform/x86/mlx-platform.c
+++ b/drivers/platform/x86/mlx-platform.c
@@ -45,6 +45,10 @@
/* LPC bus IO offsets */
#define MLXPLAT_CPLD_LPC_I2C_BASE_ADRR 0x2000
#define MLXPLAT_CPLD_LPC_REG_BASE_ADRR 0x2500
+#define MLXPLAT_CPLD_LPC_REG_AGGR_ADRR 0x253a
+#define MLXPLAT_CPLD_LPC_REG_PSU_ADRR 0x2558
+#define MLXPLAT_CPLD_LPC_REG_PWR_ADRR 0x2564
+#define MLXPLAT_CPLD_LPC_REG_FAN_ADRR 0x2588
#define MLXPLAT_CPLD_LPC_IO_RANGE 0x100
#define MLXPLAT_CPLD_LPC_I2C_CH1_OFF 0xdb
#define MLXPLAT_CPLD_LPC_I2C_CH2_OFF 0xda
@@ -56,6 +60,17 @@
MLXPLAT_CPLD_LPC_I2C_CH2_OFF) | \
MLXPLAT_CPLD_LPC_PIO_OFFSET)
+/* Masks for aggregation, psu, pwr and fan event in CPLD related registers. */
+#define MLXPLAT_CPLD_AGGR_PSU_MASK_DEF 0x08
+#define MLXPLAT_CPLD_AGGR_PWR_MASK_DEF 0x08
+#define MLXPLAT_CPLD_AGGR_FAN_MASK_DEF 0x40
+#define MLXPLAT_CPLD_AGGR_MASK_DEF (MLXPLAT_CPLD_AGGR_PSU_MASK_DEF | \
+MLXPLAT_CPLD_AGGR_FAN_MASK_DEF)
+#define MLXPLAT_CPLD_AGGR_MASK_MSN21XX 0x04
+#define MLXPLAT_CPLD_PSU_MASK GENMASK(1, 0)
+#define MLXPLAT_CPLD_PWR_MASK GENMASK(1, 0)
+#define MLXPLAT_CPLD_FAN_MASK GENMASK(3, 0)
+
/* Start channel numbers */
#define MLXPLAT_CPLD_CH1 2
#define MLXPLAT_CPLD_CH2 10
@@ -123,7 +138,7 @@ static struct i2c_mux_reg_platform_data mlxplat_mux_data[]
= {
};
/* Platform hotplug devices */
-static struct mlxcpld_hotplug_device mlxplat_mlxcpld_hotplug_psu[] = {
+static struct mlxcpld_hotplug_device mlxplat_mlxcpld_psu[] = {
{
.brdinfo = { I2C_BOARD_INFO("24c02", 0x51) },
.bus = 10,
@@ -134,7 +149,7 @@ static struct mlxcpld_hotplug_device
mlxplat_mlxcpld_hotplug_psu[] = {
},
};
-static struct mlxcpld_hotplug_device mlxplat_mlxcpld_hotplug_pwr[] = {
+static struct mlxcpld_hotplug_device mlxplat_mlxcpld_pwr[] = {
{
.brdinfo = { I2C_BOARD_INFO("dps460", 0x59) },
.bus = 10,
@@ -145,7 +160,7 @@ static struct mlxcpld_hotplug_device
mlxplat_mlxcpld_hotplug_pwr[] = {
},
};
-static struct mlxcpld_hotplug_device mlxplat_mlxcpld_hotplug_fan[] = {
+static struct mlxcpld_hotplug_device mlxplat_mlxcpld_fan[] = {
{
.brdinfo = { I2C_BOARD_INFO("24c32", 0x50) },
.bus = 11,
@@ -166,38 +181,38 @@ static struct mlxcpld_hotplug_device
mlxplat_mlxcpld_hotplug_fan[] = {
/* Platform hotplug default data */
static
-struct mlxcpld_hotplug_platform_data mlxplat_mlxcpld_hotplug_default_data = {
- .top_aggr_offset = (MLXPLAT_CPLD_LPC_REG_BASE_ADRR | 0x3a),
- .top_aggr_mask = 0x48,
- .top_aggr_psu_mask = 0x08,
- .psu_reg_offset = (MLXPLAT_CPLD_LPC_REG_BASE_ADRR | 0x58),
- .psu_mask = 0x03,
- .psu_count = ARRAY_SIZE(mlxplat_mlxcpld_hotplug_psu),
- .psu = mlxplat_mlxcpld_hotplug_psu,
- .top_aggr_pwr_mask = 0x08,
- .pwr_reg_offset = (MLXPLAT_CPLD_LPC_REG_BASE_ADRR | 0x64),
- .pwr_mask = 0x03,
- .pwr_count = ARRAY_SIZE(mlxplat_mlxcpld_hotplug_pwr),
- .pwr = mlxplat_mlxcpld_hotplug_pwr,
- .top_aggr_fan_mask = 0x40,
- .fan_reg_offset = (MLXPLAT_CPLD_LPC_REG_BASE_ADRR | 0x88),
- .fan_mask = 0x0f,
- .fan_count = ARRAY_SIZE(mlxplat_mlxcpld_hotplug_fan),
- .fan = mlxplat_mlxcpld_hotplug_fan,
+struct mlxcpld_hotplug_platform_data mlxplat_mlxcpld_default_data = {
+ .top_aggr_offset = MLXPLAT_CPLD_LPC_REG_AGGR_ADRR,
+ .top_aggr_mask = MLXPLAT_CPLD_AGGR_MASK_DEF,
+ .top_aggr_psu_mask = MLXPLAT_CPLD_AGGR_PSU_MASK_DEF,
+ .psu_reg_offset = MLXPLAT_CPLD_LPC_REG_PSU_ADRR,
+ .psu_mask = MLXPLAT_CPLD_PSU_MASK,
+ .psu_count = ARRAY_SIZE(mlxplat_mlxcpld_psu),
+ .psu = mlxplat_mlxcpld_psu,
+ .top_aggr_pwr_mask = MLXPLAT_CPLD_AGGR_PWR_MASK_DEF,
+ .pwr_reg_offset = MLXPLAT_CPLD_LPC_REG_PWR_ADRR,
+ .pwr_mask = MLXPLAT_CPLD_PWR_MASK,
+ .pwr_count = ARRAY_SIZE(mlxplat_mlxcpld_pwr),
+ .pwr = mlxplat_mlxcpld_pwr,
+ .top_aggr_fan_mask = MLXPLAT_CPLD_AGGR_FAN_MASK_DEF,
+ .fan_reg_offset = MLXPLAT_CPLD_LPC_REG_FAN_ADRR,
+ .fan_mask = MLXPLAT_CPLD_FAN_MASK,
+ .fan_count = ARRAY_SIZE(mlxplat_mlxcpld_fan),
+ .fan = mlxplat_mlxcpld_fan,
};
/* Platfo
[PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: William wu We found that the suspend process was blocked when it run into ehci/ohci module due to clk-480m of usb2-phy was disabled. The root cause is that usb2-phy suspended earlier than ehci/ohci (usb2-phy will be auto suspended if no devices plug-in). and the clk-480m provided by it was disabled if no module used. However, some suspend process related ehci/ohci are base on this clock, so we should refer it into ehci/ohci driver to prevent this case. Signed-off-by: William wu Signed-off-by: Xing Zheng --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index b65c193..228c764 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -315,8 +315,10 @@ compatible = "generic-ehci"; reg = <0x0 0xfe38 0x0 0x2>; interrupts = ; - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>; - clock-names = "hclk_host0", "hclk_host0_arb"; + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, +<&cru SCLK_USBPHY0_480M_SRC>; + clock-names = "hclk_host0", "hclk_host0_arb", + "usbphy0_480m"; phys = <&u2phy0_host>; phy-names = "usb"; status = "disabled"; @@ -326,8 +328,12 @@ compatible = "generic-ohci"; reg = <0x0 0xfe3a 0x0 0x2>; interrupts = ; - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>; - clock-names = "hclk_host0", "hclk_host0_arb"; + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, +<&cru SCLK_USBPHY0_480M_SRC>; + clock-names = "hclk_host0", "hclk_host0_arb", + "usbphy0_480m"; + phys = <&u2phy0_host>; + phy-names = "usb"; status = "disabled"; }; @@ -335,8 +341,10 @@ compatible = "generic-ehci"; reg = <0x0 0xfe3c 0x0 0x2>; interrupts = ; - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>; - clock-names = "hclk_host1", "hclk_host1_arb"; + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>, +<&cru SCLK_USBPHY1_480M_SRC>; + clock-names = "hclk_host1", "hclk_host1_arb", + "usbphy1_480m"; phys = <&u2phy1_host>; phy-names = "usb"; status = "disabled"; @@ -346,8 +354,12 @@ compatible = "generic-ohci"; reg = <0x0 0xfe3e 0x0 0x2>; interrupts = ; - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>; - clock-names = "hclk_host1", "hclk_host1_arb"; + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>, +<&cru SCLK_USBPHY1_480M_SRC>; + clock-names = "hclk_host1", "hclk_host1_arb", + "usbphy1_480m"; + phys = <&u2phy1_host>; + phy-names = "usb"; status = "disabled"; }; -- 2.7.4
Re: [PATCH v2 1/2] iio: adc: hx711: Add DT binding for avia,hx711
On 12/14/2016 10:59 AM, Andreas Klinger wrote: > Add DT bindings for avia,hx711 > Add vendor avia to vendor list > > Signed-off-by: Andreas Klinger > --- > .../devicetree/bindings/iio/adc/avia-hx711.txt | 21 > + > .../devicetree/bindings/vendor-prefixes.txt | 1 + > 2 files changed, 22 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt > > diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt > b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt > new file mode 100644 > index ..6a4659fc7a4f > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt > @@ -0,0 +1,21 @@ > +* AVIA HX711 ADC chip for weight cells > + Bit-banging driver > + > +Required properties: > + - compatible: Should be "avia,hx711" > + - sck-gpios:Definition of the GPIO for the clock > + - dout-gpios: Definition of the GPIO for data-out > + See Documentation/devicetree/bindings/gpio/gpio.txt > + > +Recommended properties: > + - gain: Gain select, can be 32, 64 or 128 > + default is 128 If the gain is software programmable it should be exposed by the driver allowing the application to change it rather than putting it in the devicetree.
[patch v1 0/1] platform/x86: mlx-platform: mlxcpld-hotplug driver notes
This patch contains the non-functional fixes, pointed out by Andy. I was waiting with sending the patch until the patch which moves mlx-platform driver from arch/x86/platform/mellanox to drivers/platform/x86 folder is accepted. Now after the below patches are committed to the testing branch: platform/x86: mlx-platform: Move module from arch/x86 is committed. platform/x86: mlx-platform: Add mlxcpld-hotplug driver registration a15e902e1a00715edc09bd1862e27f84f0a86fda 4065133df054abf4f7f41bdc15af0c7a1fd66d71 6b45a3612118878ab4f221ce49997e67687ef588 I'd like to apply the comments pointed out by Andy: - Make names of hotplug devices shorter; - Change register offset assignment to defines; - Add defines for the all event masks; - Use PLATFORM_DEVID_NONE instead of -1; Vadim Pasternak (1): platform/x86: mlx-platform: mlxcpld-hotplug driver style fixes drivers/platform/x86/mlx-platform.c | 84 ++--- 1 file changed, 50 insertions(+), 34 deletions(-) -- 2.1.4
Re: Fw: [lkp-developer] [sched,rcu] cf7a2dca60: [No primary change] +186% will-it-scale.time.involuntary_context_switches
On Tue 13-12-16 07:14:08, Paul E. McKenney wrote:
> Just FYI for the moment...
>
> So even with the slowed-down checking, making cond_resched() do what
> cond_resched_rcu_qs() does results in a smallish but quite measurable
> degradation according to 0day.
So if I understand those results properly, the reason seems to be the
increased involuntary context switches, right? Or am I misreading the
data?
I am looking at your "sched,rcu: Make cond_resched() provide RCU
quiescent state" in linux-next and I am wondering whether rcu_all_qs has
to be called unconditionally and not only when should_resched failed few
times? I guess you have discussed that with Peter already but do not
remember the outcome.
Thanks for letting my know!
> I will try some things to reduce the
> impact, but it is quite possible that we will need to live with both
> interfaces.
Thanks a lot for your time!
> Thanx, Paul
>
> - Forwarded message from kernel test robot
> -
>
> Date: Mon, 12 Dec 2016 13:52:28 +0800
> From: kernel test robot
> TO: "Paul E. McKenney"
> Cc: l...@01.org
> Subject: [lkp-developer] [sched,rcu] cf7a2dca60: [No primary change] +186%
> will-it-scale.time.involuntary_context_switches
>
> Greeting,
>
> There is no primary kpi change in this test, below is the data collected
> through multiple monitors running background just for your information.
>
>
> commit: cf7a2dca6056544bb04a8f819fbbdb415bdb2933 ("sched,rcu: Make
> cond_resched() provide RCU quiescent state")
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> dev.2016.12.05c
>
> in testcase: will-it-scale
> on test machine: 32 threads Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz with 64G
> memory
> with following parameters:
>
> test: unlink2
> cpufreq_governor: performance
>
> test-description: Will It Scale takes a testcase and runs it from 1 through
> to n parallel copies to see if the testcase will scale. It builds both a
> process and threads based test in order to see any differences between the
> two.
> test-url: https://github.com/antonblanchard/will-it-scale
>
>
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
> testcase/path_params/tbox_group/run:
> will-it-scale/unlink2-performance/lkp-sb03
>
> 15705d6709cb6ba6 cf7a2dca6056544bb04a8f819f
> --
> %stddev change %stddev
> \ |\
> 116286 114432will-it-scale.per_process_ops
> 20902 ± 5% 186% 59731 ± 5%
> will-it-scale.time.involuntary_context_switches
> 2694 ± 8%61% 4344vmstat.system.cs
> 10903 ± 99% -1e+04148 ± 5%
> latency_stats.max.wait_on_page_bit.__migration_entry_wait.migration_entry_wait.do_swap_page.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
> 3583 ± 38% 1e+04 14010 ± 51%
> latency_stats.sum.ep_poll.SyS_epoll_wait.entry_SYSCALL_64_fastpath
> 4143 ± 24% 1e+04 14549 ± 51%
> latency_stats.sum.ep_poll.SyS_epoll_wait.do_syscall_64.return_from_SYSCALL_64
> 271108 ± 71% -2e+05 66364 ± 32%
> latency_stats.sum.wait_on_page_bit.__migration_entry_wait.migration_entry_wait.do_swap_page.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
> 834637 ± 8%62%1351381perf-stat.context-switches
> 16449 ± 3%54% 25349 ± 3% perf-stat.cpu-migrations
> 25.94 35% 35.02perf-stat.node-store-miss-rate%
> 2.534e+09 32% 3.335e+09perf-stat.node-store-misses
> 1.002e+12 4% 1.043e+12perf-stat.dTLB-stores
> 50923913 3% 52692115perf-stat.iTLB-loads
> 1.696e+12 1.745e+12perf-stat.dTLB-loads
> 1.258e+12 1.291e+12perf-stat.branch-instructions
> 6.132e+12 6.274e+12perf-stat.instructions
> 0.370.38perf-stat.ipc
> 0.37 -3% 0.35perf-stat.branch-miss-rate%
> 29.83 -4% 28.66perf-stat.cache-miss-rate%
> 1.117e+10 -4% 1.071e+10perf-stat.cache-misses
> 7.232e+09 -14% 6.187e+09perf-stat.node-stores
--
Michal Hocko
SUSE Labs
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-14 11:02, Dodji Seketeli wrote: > Michal Marek a écrit: > >>> Libabigail does a "whole binary" analysis of types. >>> >>> So, consider the point of use of the type 'struct s1*'. Even if 'struct >>> s' is just forward-declared at that point, the declaration of struct s1 >>> is "resolved" to its definition. Even if the definition comes later in >>> the binary. >> >> But there isn't any definition of struct s1 in t1.o. Does abidiff >> "steal" the definition from the other object file? That would be >> legitimate, I'm just curious. > > If there is another translation unit in the *same* binary that defines > struct s1, then yes, it's "stolen", as you say. > > But if in the entire binary, struct s1 is just declared (not defined), > then it'll compare equal to any struct s1 that is defined in the > *second* binary. That makes sense, thanks. Michal
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On 2016-12-14 10:15, Michal Marek wrote:
> A minimal example would be
>
> t1.c:
> struct s1;
> struct s2 {
> int i;
> }
> struct s3 {
> struct s1 *ptr1;
> struct s2 *ptr2;
> }
> void foo(struct s3*);
> EXPORT_SYMBOL(foo);
>
> t2.c:
> struct s1 {
> int j;
> }
> struct s2;
> struct s3 {
> struct s1 *ptr1;
> struct s2 *ptr2;
> }
> void foo(struct s3*);
> EXPORT_SYMBOL(foo);
Note that the above, if passed to genksyms verbatim, would result in
genksyms treating all the types as internal. Here is a complete
example including linemarkers:
$ cat t1.i
# 1 "t1.c"
# 1 ""
# 1 ""
# 1 "t1.c"
# 1 "t1.h" 1
# 1 "t.h" 1
struct s1;
struct s2;
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
};
# 2 "t1.h" 2
struct s2 {
int i;
};
# 2 "t1.c" 2
void foo(struct s3 *s) { }
EXPORT_SYMBOL(foo);
$ cat t2.i
# 1 "t2.c"
# 1 ""
# 1 ""
# 1 "t2.c"
# 1 "t2.h" 1
# 1 "t.h" 1
struct s1;
struct s2;
struct s3 {
struct s1 *ptr1;
struct s2 *ptr2;
};
# 2 "t2.h" 2
struct s1 {
int j;
};
# 2 "t2.c" 2
void foo(struct s3 *s) { }
EXPORT_SYMBOL(foo);
$ ./scripts/genksyms/genksyms -D
__crc_foo = 0xf731cef8 ;
$ ./scripts/genksyms/genksyms -D
__crc_foo = 0xc925dae5 ;
Michal
答复: [PATCH] fuse: freezing abort when use wait_event_killable{,_exclusive}().
Rafael,
Any questions about the patch, please let me know.
Thanks!
BR,
Cui Li Fei
发件人: 崔立飞
发送时间: 2016年12月8日 14:31
收件人: Rafael J. Wysocki
抄送: linux-kernel@vger.kernel.org; mik...@szeredi.hu; pa...@ucw.cz;
len.br...@intel.com; linux-fsde...@vger.kernel.org; v...@zeniv.linux.org.uk;
朴英敏; 刘才; Jiri Kosina; 崔立飞
主题: 答复: [PATCH] fuse: freezing abort when use
wait_event_killable{,_exclusive}().
Hi Rafael,
The fuse we used is without the commit "fuse: don't mess with blocking signals"
committed by Al Viro.
So we find the issue SIGBUS. In the page fault, trying to read page in fuse is
interrupted,
which will lead to SIGBUS issue.
All Android platforms, include Android N, have the SIGUBS issue. All the SIGBUS
issues are produced
in the freezing process.
In our Android platform, the root-cause of SIGBUS is :
suspend procedure will set the signal pending flag(TIF_SIGPENDING) and then
wake up the task
which is TASK_INTERRUPTIBLE status . The request_wait_answer, which calls
wait_event_interruptible,
is interrupted and the fuse request is still in pending status, which leads to
SIGBUS sent to caller.
This issue can be reproduced by adding delays in funciton handle_read,
which is in the Android sdcard daemon process.
So we merge the commit "fuse: don't mess with blocking signals", which just use
wait_event_killable{,_exclusive}().
It fix the SIGBUS issue. But the freezing will fail, because the freezing
procedure cannot wake up the task which
is in TASK_KILLABLE(TASK_WAKEKILL | TASK_UNINTERRUPTIBLE) status. And the
suspend procedure will abort
until the time is out.
In this patch, we try to fix the issue mentioned above.
> ---
> fs/fuse/dev.c | 30 ++
> include/linux/freezer.h | 26 ++
> 2 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 70ea57c..e33a081 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> MODULE_ALIAS_MISCDEV(FUSE_MINOR);
> MODULE_ALIAS("devname:fuse");
> @@ -99,6 +100,19 @@ void fuse_request_free(struct fuse_req *req)
> kmem_cache_free(fuse_req_cachep, req);
> }
>
> +static void block_sigs(sigset_t *oldset)
> +{
> + sigset_t mask;
> +
> + siginitsetinv(&mask, sigmask(SIGKILL));
> + sigprocmask(SIG_BLOCK, &mask, oldset);
> +}
> +
> +static void restore_sigs(sigset_t *oldset)
> +{
> + sigprocmask(SIG_SETMASK, oldset, NULL);
> +}
> +
> void __fuse_get_request(struct fuse_req *req)
> {
> atomic_inc(&req->count);
> @@ -134,13 +148,18 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn
> *fc, unsigned npages,
> bool for_background)
> {
> struct fuse_req *req;
> + sigset_t oldset;
> + int intr;
> int err;
> atomic_inc(&fc->num_waiting);
>
> if (fuse_block_alloc(fc, for_background)) {
> err = -EINTR;
> - if (wait_event_killable_exclusive(fc->blocked_waitq,
> - !fuse_block_alloc(fc, for_background)))
> + block_sigs(&oldset);
> + intr = wait_fatal_freezable(fc->blocked_waitq,
> + !fuse_block_alloc(fc, for_background), true);
> + restore_sigs(&oldset);
> + if (intr)
> goto out;
> }
> /* Matches smp_wmb() in fuse_set_initialized() */
> @@ -427,9 +446,12 @@ static void request_wait_answer(struct fuse_conn *fc,
> struct fuse_req *req)
> }
>
> if (!test_bit(FR_FORCE, &req->flags)) {
> + sigset_t oldset;
> /* Only fatal signals may interrupt this */
> - err = wait_event_killable(req->waitq,
> - test_bit(FR_FINISHED, &req->flags));
> + block_sigs(&oldset);
> + err = wait_fatal_freezable(req->waitq,
> + test_bit(FR_FINISHED, &req->flags), false);
> + restore_sigs(&oldset);
> if (!err)
> return;
>
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index dd03e83..2504cd0 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -256,6 +256,22 @@ static inline int
> freezable_schedule_hrtimeout_range(ktime_t *expires,
> __retval; \
> })
>
> +#define wait_fatal_freezable(wq, condition, exclusive)
> \
> +({ \
> + int __ret = 0; \
> + do { \
> + if (exclusive) \
> + __ret = wait_event_interruptible_ex
[PATCH 0/3] Add and export clk-480m clocks for ehci and ohci on RK3399
Hi, This patches would like to fix the USB suspend block without the clk-480m clock. Let's add and export them to control them. Thanks. William wu (1): arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399 Xing Zheng (2): clk: rockchip: rk3399: add USBPHYx_480M_SRC clock IDs clk: rockchip: rk3399: export 480M_SRC clocks id for usbphy0/usbphy1 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 drivers/clk/rockchip/clk-rk3399.c| 4 ++-- include/dt-bindings/clock/rk3399-cru.h | 2 ++ 3 files changed, 24 insertions(+), 10 deletions(-) -- 2.7.4
Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another
On Tue 13-12-16 18:11:01, David Arendt wrote: > Hi, > > I receive the following page allocation stall while copying lots of > large files from one btrfs hdd to another. > > Dec 13 13:04:29 server kernel: kworker/u16:8: page allocation stalls for > 12260ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL) > Dec 13 13:04:29 server kernel: CPU: 0 PID: 24959 Comm: kworker/u16:8 Tainted: > P O4.9.0 #1 [...] > Dec 13 13:04:29 server kernel: Call Trace: > Dec 13 13:04:29 server kernel: [] ? dump_stack+0x46/0x5d > Dec 13 13:04:29 server kernel: [] ? warn_alloc+0x111/0x130 > Dec 13 13:04:33 server kernel: [] ? > __alloc_pages_nodemask+0xbe8/0xd30 > Dec 13 13:04:33 server kernel: [] ? > pagecache_get_page+0xe4/0x230 > Dec 13 13:04:33 server kernel: [] ? > alloc_extent_buffer+0x10b/0x400 > Dec 13 13:04:33 server kernel: [] ? > btrfs_alloc_tree_block+0x125/0x560 OK, so this is find_or_create_page(mapping, index, GFP_NOFS|__GFP_NOFAIL) The main question is whether this really needs to be NOFS request... > Dec 13 13:04:33 server kernel: [] ? > read_extent_buffer_pages+0x21f/0x280 > Dec 13 13:04:33 server kernel: [] ? > __btrfs_cow_block+0x141/0x580 > Dec 13 13:04:33 server kernel: [] ? > btrfs_cow_block+0x100/0x150 > Dec 13 13:04:33 server kernel: [] ? > btrfs_search_slot+0x1e9/0x9c0 > Dec 13 13:04:33 server kernel: [] ? > __set_extent_bit+0x512/0x550 > Dec 13 13:04:33 server kernel: [] ? > lookup_inline_extent_backref+0xf5/0x5e0 > Dec 13 13:04:34 server kernel: [] ? > set_extent_bit+0x24/0x30 > Dec 13 13:04:34 server kernel: [] ? > update_block_group.isra.34+0x114/0x380 > Dec 13 13:04:34 server kernel: [] ? > __btrfs_free_extent.isra.35+0xf4/0xd20 > Dec 13 13:04:34 server kernel: [] ? > btrfs_merge_delayed_refs+0x61/0x5d0 > Dec 13 13:04:34 server kernel: [] ? > __btrfs_run_delayed_refs+0x902/0x10a0 > Dec 13 13:04:34 server kernel: [] ? > btrfs_run_delayed_refs+0x90/0x2a0 > Dec 13 13:04:34 server kernel: [] ? > delayed_ref_async_start+0x84/0xa0 What would cause the reclaim recursion? > Dec 13 13:04:34 server kernel: Mem-Info: > Dec 13 13:04:34 server kernel: active_anon:20 inactive_anon:34 > isolated_anon:0\x0a active_file:7370032 inactive_file:450105 > isolated_file:320\x0a unevictable:0 dirty:522748 writeback:189 > unstable:0\x0a slab_reclaimable:178255 slab_unreclaimable:124617\x0a > mapped:4236 shmem:0 pagetables:1163 bounce:0\x0a free:38224 free_pcp:241 > free_cma:0 This speaks for itself. There is a lot of dirty data, basically no anonymous memory and GFP_NOFS cannot do much to reclaim obviously. This is either a configuraion bug as somebody noted down the thread (setting the dirty_ratio) or suboptimality of the btrfs code which might request NOFS even though it is not strictly necessary. This would be more for btrfs developers. -- Michal Hocko SUSE Labs
[PATCH] serial: fsl_lpuart: Remove the alias node dependence
From: Yuan Yao
Numbering the ttyLPn space should not depend on the generic name
"serial".
If don't add the alias node like:"serial0 = &lpuart0;", then lpuart
will probe failed:
[0.773410] fsl-lpuart 295.serial: failed to get alias id, errno -19
So remove the alias node dependence, and add the support for allocate the
line port automatically.
Signed-off-by: Yuan Yao
---
drivers/tty/serial/fsl_lpuart.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index a1c6519..c6d639f 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -231,6 +231,8 @@
#define DEV_NAME "ttyLP"
#define UART_NR6
+static DECLARE_BITMAP(linemap, UART_NR);
+
struct lpuart_port {
struct uart_portport;
struct clk *clk;
@@ -1963,9 +1965,13 @@ static int lpuart_probe(struct platform_device *pdev)
ret = of_alias_get_id(np, "serial");
if (ret < 0) {
- dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
- return ret;
+ ret = find_first_zero_bit(linemap, UART_NR);
+ if (ret >= UART_NR) {
+ dev_err(&pdev->dev, "port line is full, add device
failed\n");
+ return ret;
+ }
}
+ set_bit(ret, linemap);
sport->port.line = ret;
sport->lpuart32 = of_device_is_compatible(np, "fsl,ls1021a-lpuart");
@@ -2047,6 +2053,7 @@ static int lpuart_remove(struct platform_device *pdev)
struct lpuart_port *sport = platform_get_drvdata(pdev);
uart_remove_one_port(&lpuart_reg, &sport->port);
+ clear_bit(sport->port.line, linemap);
clk_disable_unprepare(sport->clk);
--
2.1.0.27.g96db324
Re: [PATCH] vfio/pci: Support error recovery
Sorry for late. after reading all your comments, I think I will try the solution 1. On 12/13/2016 03:12 AM, Alex Williamson wrote: > On Mon, 12 Dec 2016 21:49:01 +0800 > Cao jin wrote: > >> Hi, >> I have 2 solutions(high level design) came to me, please see if they are >> acceptable, or which one is acceptable. Also have some questions. >> >> 1. block guest access during host recovery >> >>add new field error_recovering in struct vfio_pci_device to >>indicate host recovery status. aer driver in host will still do >>reset link >> >>- set error_recovering in vfio-pci driver's error_detected, used to >> block all kinds of user access(config space, mmio) >>- in order to solve concurrent issue of device resetting & user >> access, check device state[*] in vfio-pci driver's resume, see if >> device reset is done, if it is, then clear"error_recovering", or >> else new a timer, check device state periodically until device >> reset is done. (what if device reset don't end for a long time?) >>- In qemu, translate guest link reset to host link reset. >> A question here: we already have link reset in host, is a second >> link reset necessary? why? >> >>[*] how to check device state: reading certain config space >>register, check return value is valid or not(All F's) > > Isn't this exactly the path we were on previously? Yes, it is basically the previous path, plus the optimization. > There might be an > optimization that we could skip back-to-back resets, but how can you > necessarily infer that the resets are for the same thing? If the user > accesses the device between resets, can you still guarantee the guest > directed reset is unnecessary? If time passes between resets, do you > know they're for the same event? How much time can pass between the > host and guest reset to know they're for the same event? In the > process of error handling, which is more important, speed or > correctness? > I think vfio driver itself won't know what each reset comes for, and I don't quite understand why should vfio care this question, is this a new question in the design? But I think it make sense that the user access during 2 resets maybe a trouble for guest recovery, misbehaved user could be out of our imagination. Correctness is more important. If I understand you right, let me make a summary: host recovery just does link reset, which is incomplete, so we'd better do a complete guest recovery for correctness. >> 2. skip link reset in aer driver of host kernel, for vfio-pci. >>Let user decide how to do serious recovery >> >>add new field "user_driver" in struct pci_dev, used to skip link >>reset for vfio-pci; add new field "link_reset" in struct >>vfio_pci_device to indicate link has been reset or not during >>recovery >> >>- set user_driver in vfio_pci_probe(), to skip link reset for >> vfio-pci in host. >>- (use a flag)block user access(config, mmio) during host recovery >> (not sure if this step is necessary) >>- In qemu, translate guest link reset to host link reset. >>- In vfio-pci driver, set link_reset after VFIO_DEVICE_PCI_HOT_RESET >> is executed >>- In vfio-pci driver's resume, new a timer, check "link_reset" field >> periodically, if it is set in reasonable time, then clear it and >> delete timer, or else, vfio-pci driver will does the link reset! > > What happens in the case of a multifunction device where each function > is part of a separate IOMMU group and one function is hot-removed from > the user? We can't do a link reset on that function since the other > function is still in use. We have no choice but release a device in an > unknown state back to the host. hot-remove from user, do you mean, for example, all functions assigned to VM, then suddenly a person does something like following $ echo :06:00.0 > /sys/bus/pci/drivers/vfio-pci/unbind $ echo :06:00.0 > /sys/bus/pci/drivers/igb/bind to return device to host driver, or don't bind it to host driver, let it in driver-less state??? > As previously discussed, we don't > expect that any sort of function-level FLR will necessarily reset the > device to the same state. I also don't really like vfio-pci taking > over error handling capabilities from the PCI-core. That's redundant > code and extra maintenance overhead. > I understand the concern, so I suppose solution 1 is preferred. -- Sincerely, Cao jin >> A quick question: >> I don't know how devices is divided into iommu groups, is it possible >> for functions in a multi-function device to be split into different groups? > > Yes, if a multifunction device supports ACS or if we have quirks to > expose that the functions do not perform internal peer-to-peer, then > they may be in separate IOMMU groups, depending on the rest of the PCI > topology. See: > > http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html > > Thanks, > A
[GIT PULL] sound updates for 4.10
Linus, please pull sound updates for 4.10 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.10-rc1 The topmost commit is 995c6a7fd9b9212abdf01160f6ce3193176be503 sound updates for 4.10-rc1 No dramatic changes are found in this development cycle, but as usual, many commits are applied in a wide range of drivers. Most of big changes are in ASoC, where a few bits of framework work and quite a lot of cleanups and improvements to existing code have been done. The rest are usual stuff, a few HD-audio and USB-audio quirks and fixes, as well as the drop of kthread usages in the whole subsystem. Below are some highlights: ASoC: - Support for stereo DAPM controls - Some initial work on the of-graph sound card - regmap conversions of the remaining AC'97 drivers - A new version of the topology ABI; this should be backward compatible - Updates / cleanups of rsnd, sunxi, sti, nau8825, samsung, arizona, Intel skylake, atom-sst - New drivers for Cirrus Logic CS42L42, Qualcomm MSM8916-WCD, and Realtek RT5665 USB-audio: - Yet another race fix at disconnection - Tolerated packet size calculation for some Android devices - Quirks for Axe-Fx II, QuickCam, TEAC 501/503 HD-audio: - Improvement of Dell pin fixup mapping - Quirks for HP Z1 Gen3, Alienware 15 R2 2016 and ALC622 headset mic Misc: - Replace all kthread usages with simple works Adam Thomson (1): ASoC: da7219: Improve pop/click performance for sensitive HPs Alberto Aguirre (1): ALSA: usb-audio: add implicit fb quirk for Axe-Fx II Alexey Khoroshilov (1): SoC: mxs-saif: check validity of ids in mxs_saif_probe() Andreas Pape (1): ALSA: usb-audio: more tolerant packetsize Andrej Krutak (1): ALSA: line6: Claim pod x3 usb data interface Arnaud Pouliquen (5): ASoC: sti: fix errors management ASoC: sti: reset refactoring ASoC: sti: clean unused include ASoC: sti-sas: clean legacy in sti-sas ASoC: sti-sas: add missing return in messages strings Arnd Bergmann (2): ASoC: lpass-platform: initialize dma channel number ASoC: topology: avoid uninitialized kcontrol_type Axel Lin (6): regulator: rk808: Use rdev_get_id() to access id of regulator ASoC: cs35l34: Remove CS35L34_CHIP_ID from cs35l34_readable_register ASoC: msm8916-wcd-analog: Update correct register setting for MIC BIAS Internal1 ASoC: rt5665: Fix missing mutex_unlock in rt5665_calibrate ASoC: rt5665: Use devm_gpio_request_one() ASoC: cs35l34: Simplify the logic to set CS35L34_MCLK_CTL setting Bard Liao (10): ASoC: rt5663: rename rt5668 as rt5663 v2 ASoC: rt5660: enable MCLK detection ASoC: rt5640: enable MCLK detection ASoC: rt5670: Enable MCLK detection ASoC: rt5670: increse LDO power ASoC: rt5640: add Mono ADC Capture Switch control ASoC: rt286: remove unnecessary selection in Kconfig ASoC: add rt5665 codec driver ASoC: rl6231: add 19.2M to 4.096M pll preset table ASoC: rt298: disable IRQ when jack is NULL Charles Keepax (18): ASoC: arizona: Add gating for clock when used for direct MCLK ASoC: arizona: Add gating for source clocks of the FLLs ASoC: samsung: i2s: Fixup last IRQ unsafe spin lock call ASoC: cs42xx8: Mark chip ID as volatile and remove cache bypass ASoC: cs42l56: Make ID registers volatile and remove cache bypass ASoC: cs42l73: Remove cache bypass for read of ID registers ASoC: arizona: Move request of speaker IRQs into bus probe ASoC: arizona: Move request of DSP IRQ into bus probe ASoC: cs47l24: Fixup missing variable typo ASoC: arizona: Access driver data through platform from compressed ops ASoC: core: If a platform doesn't have an of_node use parent's node ASoC: wm2200: Correct types of mixer texts and values ASoC: arizona: Move notifier functions to header and make inline ASoC: arizona: Call arizona_init_notifiers for all CODECs ASoC: wm_adsp: Only write shutdown controls for active firmwares ASoC: wm_adsp: Check return value from wm_adsp_buffer_init ASoC: arizona: Remove redundant extern declarations ASoC: wm_adsp: Remove redundant extern declarations Chen-Yu Tsai (19): ASoC: dapm: Support second register for DAPM control updates ASoC: dapm: Implement stereo mixer control support ASoC: dapm: Introduce DAPM_DOUBLE dual channel control type ASoC: dapm: Introduce DAPM_DOUBLE_R dual channel dual register control type ASoC: sun4i-codec: Move data structures to add create_card call to quirks ASoC: sun4i-codec: Revise comments for register definition macros ASoC: sun4i-codec: Expand quirks to handle register offsets and card creation ASoC: sun4i-codec: Increase DMA max burst to 8 ASoC: sun4i
Re: [PATCH] block_dev: don't update file access position for sync direct IO
On Tue, Dec 13, 2016 at 09:08:18PM -0700, Jens Axboe wrote: > That's not great... Thanks, added. Ooops, yeah - we're still going through ->direct_IO for block devices. I'll take a stab at removing that, as it's just a pointless indirect call.
Re: [PATCH 6/6] media/cobalt: use pci_irq_allocate_vectors
Hi Hans, just checked the current Linux tree and cobalt still uses the old pci_enable_msi_range call. Did you queue this patch up for 4.10?
Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another
Btw. the stall should be preceded by the OOM killer invocation. Could you share the OOM report please. I am asking because such an OOM killer would be clearly pre-mature as per your meminfo. I am trying to change that code and seeing your numbers might help me. Thanks! On Wed 14-12-16 11:17:43, Michal Hocko wrote: > On Tue 13-12-16 18:11:01, David Arendt wrote: > > Hi, > > > > I receive the following page allocation stall while copying lots of > > large files from one btrfs hdd to another. > > > > Dec 13 13:04:29 server kernel: kworker/u16:8: page allocation stalls for > > 12260ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL) > > Dec 13 13:04:29 server kernel: CPU: 0 PID: 24959 Comm: kworker/u16:8 > > Tainted: P O4.9.0 #1 > [...] > > Dec 13 13:04:29 server kernel: Call Trace: > > Dec 13 13:04:29 server kernel: [] ? dump_stack+0x46/0x5d > > Dec 13 13:04:29 server kernel: [] ? > > warn_alloc+0x111/0x130 > > Dec 13 13:04:33 server kernel: [] ? > > __alloc_pages_nodemask+0xbe8/0xd30 > > Dec 13 13:04:33 server kernel: [] ? > > pagecache_get_page+0xe4/0x230 > > Dec 13 13:04:33 server kernel: [] ? > > alloc_extent_buffer+0x10b/0x400 > > Dec 13 13:04:33 server kernel: [] ? > > btrfs_alloc_tree_block+0x125/0x560 > > OK, so this is > find_or_create_page(mapping, index, GFP_NOFS|__GFP_NOFAIL) > > The main question is whether this really needs to be NOFS request... > > > Dec 13 13:04:33 server kernel: [] ? > > read_extent_buffer_pages+0x21f/0x280 > > Dec 13 13:04:33 server kernel: [] ? > > __btrfs_cow_block+0x141/0x580 > > Dec 13 13:04:33 server kernel: [] ? > > btrfs_cow_block+0x100/0x150 > > Dec 13 13:04:33 server kernel: [] ? > > btrfs_search_slot+0x1e9/0x9c0 > > Dec 13 13:04:33 server kernel: [] ? > > __set_extent_bit+0x512/0x550 > > Dec 13 13:04:33 server kernel: [] ? > > lookup_inline_extent_backref+0xf5/0x5e0 > > Dec 13 13:04:34 server kernel: [] ? > > set_extent_bit+0x24/0x30 > > Dec 13 13:04:34 server kernel: [] ? > > update_block_group.isra.34+0x114/0x380 > > Dec 13 13:04:34 server kernel: [] ? > > __btrfs_free_extent.isra.35+0xf4/0xd20 > > Dec 13 13:04:34 server kernel: [] ? > > btrfs_merge_delayed_refs+0x61/0x5d0 > > Dec 13 13:04:34 server kernel: [] ? > > __btrfs_run_delayed_refs+0x902/0x10a0 > > Dec 13 13:04:34 server kernel: [] ? > > btrfs_run_delayed_refs+0x90/0x2a0 > > Dec 13 13:04:34 server kernel: [] ? > > delayed_ref_async_start+0x84/0xa0 > > What would cause the reclaim recursion? > > > Dec 13 13:04:34 server kernel: Mem-Info: > > Dec 13 13:04:34 server kernel: active_anon:20 inactive_anon:34 > > isolated_anon:0\x0a active_file:7370032 inactive_file:450105 > > isolated_file:320\x0a unevictable:0 dirty:522748 writeback:189 > > unstable:0\x0a slab_reclaimable:178255 slab_unreclaimable:124617\x0a > > mapped:4236 shmem:0 pagetables:1163 bounce:0\x0a free:38224 free_pcp:241 > > free_cma:0 > > This speaks for itself. There is a lot of dirty data, basically no > anonymous memory and GFP_NOFS cannot do much to reclaim obviously. This > is either a configuraion bug as somebody noted down the thread (setting > the dirty_ratio) or suboptimality of the btrfs code which might request > NOFS even though it is not strictly necessary. This would be more for > btrfs developers. > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs
Re: [PATCH 5/7] blk-mq-sched: add framework for MQ capable IO schedulers
On 12/13/2016 04:14 PM, Jens Axboe wrote:
> On 12/13/2016 06:56 AM, Bart Van Assche wrote:
>> On 12/08/2016 09:13 PM, Jens Axboe wrote:
>>> +struct request *blk_mq_sched_alloc_shadow_request(struct request_queue *q,
>>> + struct blk_mq_alloc_data
>>> *data,
>>> + struct blk_mq_tags *tags,
>>> + atomic_t *wait_index)
>>> +{
>>
>> Using the word "shadow" in the function name suggests to me that there
>> is a shadow request for every request and a request for every shadow
>> request. However, my understanding from the code is that there can be
>> requests without shadow requests (for e.g. a flush) and shadow requests
>> without requests. Shouldn't the name of this function reflect that, e.g.
>> by using "sched" or "elv" in the function name instead of "shadow"?
>
> Shadow might not be the best name. Most do have shadows though, it's
> only the rare exception like the flush, that you mention. I'll see if I
> can come up with a better name.
Hello Jens,
One aspect of this patch series that might turn out to be a maintenance
burden is the copying between original and shadow requests. It is easy
to overlook that rq_copy() has to be updated if a field would ever be
added to struct request. Additionally, having to allocate two requests
structures per I/O instead of one will have a runtime overhead. Do you
think the following approach would work?
- Instead of using two request structures per I/O, only use a single
request structure.
- Instead of storing one tag in the request structure, store two tags
in that structure. One tag comes from the I/O scheduler tag set
(size: nr_requests) and the other from the tag set associated with
the block driver (size: HBA queue depth).
- Only add a request to the hctx dispatch list after a block driver tag
has been assigned. This means that an I/O scheduler must keep a
request structure on a list it manages itself as long as no block
driver tag has been assigned.
- sysfs_list_show() is modified such that it shows both tags.
Thanks,
Bart.
