* Re: [PATCH net-next v6 0/4] bpf: add two helpers to read perf event enabled/running time
From: David Miller @ 2017-10-04 23:00 UTC (permalink / raw)
To: yhs; +Cc: peterz, rostedt, ast, daniel, netdev, kernel-team
In-Reply-To: <20171002224218.3181418-1-yhs@fb.com>
From: Yonghong Song <yhs@fb.com>
Date: Mon, 2 Oct 2017 15:42:14 -0700
> [Dave, Peter,
>
> Previous communcation shows that this patch may potentially have
> merge conflict with upcoming tip changes in the next merge window.
>
> Could you advise how this patch should proceed?
>
> Thanks!
> ]
Indeed, Peter how do you want to handle this?
Thanks.
^ permalink raw reply
* [Intel-wired-lan] [PATCH] PCI: Check/Set ARI capability before setting numVFs
From: Bjorn Helgaas @ 2017-10-04 23:01 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20171004155258.35634-1-anthony.l.nguyen@intel.com>
On Wed, Oct 04, 2017 at 08:52:58AM -0700, Tony Nguyen wrote:
> This fixes a bug that can occur if an AER error is encountered while SRIOV
> devices are present.
>
> This issue was seen by doing the following. Inject an AER error to a device
> that has SRIOV devices. After the device has recovered, remove the driver.
> Reload the driver and enable SRIOV which causes the following crash to
> occur:
>
> kernel BUG at drivers/pci/iov.c:157!
> invalid opcode: 0000 [#1] SMP
> CPU: 36 PID: 2295 Comm: bash Not tainted 4.14.0-rc1+ #74
> Hardware name: Supermicro X9DAi/X9DAi, BIOS 3.0a 04/29/2014
> task: ffff9fa41cd45a00 task.stack: ffffb4b2036e8000
> RIP: 0010:pci_iov_add_virtfn+0x2eb/0x350
> RSP: 0018:ffffb4b2036ebcb8 EFLAGS: 00010286
> RAX: 00000000fffffff0 RBX: ffff9fa42c1c8800 RCX: ffff9fa421ce2388
> RDX: 00000000df900000 RSI: ffff9fa8214fb388 RDI: 00000000df903fff
> RBP: ffffb4b2036ebd18 R08: ffff9fa421ce23b8 R09: ffffb4b2036ebc2c
> R10: ffff9fa42c1a5548 R11: 000000000000058e R12: ffff9fa8214fb000
> R13: ffff9fa42c1a5000 R14: ffff9fa8214fb388 R15: 0000000000000000
> FS: 00007f60724b6700(0000) GS:ffff9fa82f300000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000559eca8b0f40 CR3: 0000000864146000 CR4: 00000000001606e0
> Call Trace:
> pci_enable_sriov+0x353/0x440
> ixgbe_pci_sriov_configure+0xd5/0x1f0 [ixgbe]
> sriov_numvfs_store+0xf7/0x170
> dev_attr_store+0x18/0x30
> sysfs_kf_write+0x37/0x40
> kernfs_fop_write+0x120/0x1b0
> __vfs_write+0x37/0x170
> ? __alloc_fd+0x3f/0x170
> ? set_close_on_exec+0x30/0x70
> vfs_write+0xb5/0x1a0
> SyS_write+0x55/0xc0
> entry_SYSCALL_64_fastpath+0x1a/0xa5
> RIP: 0033:0x7f6071bafc20
> RSP: 002b:00007ffe7d42ba48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 0000559eca8b0f30 RCX: 00007f6071bafc20
> RDX: 0000000000000002 RSI: 0000559eca961f60 RDI: 0000000000000001
> RBP: 00007f6071e78ae0 R08: 00007f6071e7a740 R09: 00007f60724b6700
> R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000559eca892170
> RIP: pci_iov_add_virtfn+0x2eb/0x350 RSP: ffffb4b2036ebcb8
>
> The occurs since during AER recovery the ARI Capable Hierarchy bit,
> which can affect the values for First VF Offset and VF Stride, is not set
> until after pci_iov_set_numvfs() is called.
Can you elaborate on where exactly this happens? The only place we
explicitly set PCI_SRIOV_CTRL_ARI is in sriov_init(), which is only
called at enumeration-time. So I'm guessing you're talking about this
path:
ixgbe_io_slot_reset
pci_restore_state
pci_restore_iov_state
sriov_restore_state
pci_iov_set_numvfs
where we don't set PCI_SRIOV_CTRL_ARI at all. The fact that you say
PCI_SRIOV_CTRL_ARI isn't set until *after* pci_iov_set_numvfs() is
called suggests that it is being set *somewhere*, but I don't know
where.
> This can cause the iov
> structure to be populated with values that are incorrect if the bit is
> later set. Check and set this bit, if needed, before calling
> pci_iov_set_numvfs() so that the values being populated properly take
> the ARI bit into account.
>
> CC: Alexander Duyck <alexander.h.duyck@intel.com>
> CC: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/pci/iov.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 7492a65..a8896c7 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -497,6 +497,10 @@ static void sriov_restore_state(struct pci_dev *dev)
> if (ctrl & PCI_SRIOV_CTRL_VFE)
> return;
>
> + if ((iov->ctrl & PCI_SRIOV_CTRL_ARI) && !(ctrl & PCI_SRIOV_CTRL_ARI))
> + pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL,
> + ctrl | PCI_SRIOV_CTRL_ARI);
> +
> for (i = PCI_IOV_RESOURCES; i <= PCI_IOV_RESOURCE_END; i++)
> pci_update_resource(dev, i);
>
> --
> 2.9.5
>
^ permalink raw reply
* Re: [PATCH] PCI: Check/Set ARI capability before setting numVFs
From: Bjorn Helgaas @ 2017-10-04 23:01 UTC (permalink / raw)
To: Tony Nguyen
Cc: linux-pci, intel-wired-lan, linux-kernel, netdev, bhelgaas,
Alexander Duyck, Emil Tantilov
In-Reply-To: <20171004155258.35634-1-anthony.l.nguyen@intel.com>
On Wed, Oct 04, 2017 at 08:52:58AM -0700, Tony Nguyen wrote:
> This fixes a bug that can occur if an AER error is encountered while SRIOV
> devices are present.
>
> This issue was seen by doing the following. Inject an AER error to a device
> that has SRIOV devices. After the device has recovered, remove the driver.
> Reload the driver and enable SRIOV which causes the following crash to
> occur:
>
> kernel BUG at drivers/pci/iov.c:157!
> invalid opcode: 0000 [#1] SMP
> CPU: 36 PID: 2295 Comm: bash Not tainted 4.14.0-rc1+ #74
> Hardware name: Supermicro X9DAi/X9DAi, BIOS 3.0a 04/29/2014
> task: ffff9fa41cd45a00 task.stack: ffffb4b2036e8000
> RIP: 0010:pci_iov_add_virtfn+0x2eb/0x350
> RSP: 0018:ffffb4b2036ebcb8 EFLAGS: 00010286
> RAX: 00000000fffffff0 RBX: ffff9fa42c1c8800 RCX: ffff9fa421ce2388
> RDX: 00000000df900000 RSI: ffff9fa8214fb388 RDI: 00000000df903fff
> RBP: ffffb4b2036ebd18 R08: ffff9fa421ce23b8 R09: ffffb4b2036ebc2c
> R10: ffff9fa42c1a5548 R11: 000000000000058e R12: ffff9fa8214fb000
> R13: ffff9fa42c1a5000 R14: ffff9fa8214fb388 R15: 0000000000000000
> FS: 00007f60724b6700(0000) GS:ffff9fa82f300000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000559eca8b0f40 CR3: 0000000864146000 CR4: 00000000001606e0
> Call Trace:
> pci_enable_sriov+0x353/0x440
> ixgbe_pci_sriov_configure+0xd5/0x1f0 [ixgbe]
> sriov_numvfs_store+0xf7/0x170
> dev_attr_store+0x18/0x30
> sysfs_kf_write+0x37/0x40
> kernfs_fop_write+0x120/0x1b0
> __vfs_write+0x37/0x170
> ? __alloc_fd+0x3f/0x170
> ? set_close_on_exec+0x30/0x70
> vfs_write+0xb5/0x1a0
> SyS_write+0x55/0xc0
> entry_SYSCALL_64_fastpath+0x1a/0xa5
> RIP: 0033:0x7f6071bafc20
> RSP: 002b:00007ffe7d42ba48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 0000559eca8b0f30 RCX: 00007f6071bafc20
> RDX: 0000000000000002 RSI: 0000559eca961f60 RDI: 0000000000000001
> RBP: 00007f6071e78ae0 R08: 00007f6071e7a740 R09: 00007f60724b6700
> R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000559eca892170
> RIP: pci_iov_add_virtfn+0x2eb/0x350 RSP: ffffb4b2036ebcb8
>
> The occurs since during AER recovery the ARI Capable Hierarchy bit,
> which can affect the values for First VF Offset and VF Stride, is not set
> until after pci_iov_set_numvfs() is called.
Can you elaborate on where exactly this happens? The only place we
explicitly set PCI_SRIOV_CTRL_ARI is in sriov_init(), which is only
called at enumeration-time. So I'm guessing you're talking about this
path:
ixgbe_io_slot_reset
pci_restore_state
pci_restore_iov_state
sriov_restore_state
pci_iov_set_numvfs
where we don't set PCI_SRIOV_CTRL_ARI at all. The fact that you say
PCI_SRIOV_CTRL_ARI isn't set until *after* pci_iov_set_numvfs() is
called suggests that it is being set *somewhere*, but I don't know
where.
> This can cause the iov
> structure to be populated with values that are incorrect if the bit is
> later set. Check and set this bit, if needed, before calling
> pci_iov_set_numvfs() so that the values being populated properly take
> the ARI bit into account.
>
> CC: Alexander Duyck <alexander.h.duyck@intel.com>
> CC: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/pci/iov.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 7492a65..a8896c7 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -497,6 +497,10 @@ static void sriov_restore_state(struct pci_dev *dev)
> if (ctrl & PCI_SRIOV_CTRL_VFE)
> return;
>
> + if ((iov->ctrl & PCI_SRIOV_CTRL_ARI) && !(ctrl & PCI_SRIOV_CTRL_ARI))
> + pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL,
> + ctrl | PCI_SRIOV_CTRL_ARI);
> +
> for (i = PCI_IOV_RESOURCES; i <= PCI_IOV_RESOURCE_END; i++)
> pci_update_resource(dev, i);
>
> --
> 2.9.5
>
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Add erspan tunnel support.
From: William Tu @ 2017-10-04 23:02 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAOrHB_DNkfnUty=QzO5d6SAyscLXBP-teE_j0RvDaJiMHqRaaw@mail.gmail.com>
On Wed, Oct 4, 2017 at 2:31 PM, Pravin Shelar <pshelar@ovn.org> wrote:
> On Wed, Oct 4, 2017 at 5:02 AM, William Tu <u9012063@gmail.com> wrote:
>> Add type II erspan vport implementation. Since erspan protocol is
>> on top of the GRE header, the implementation is extended from the
>> existing gre implementation.
>>
>> Signed-off-by: William Tu <u9012063@gmail.com>
>> Cc: Pravin B Shelar <pshelar@ovn.org>
>
> Why are you adding ERSPAN support to compat code. Isn't this supported
> over OVS netlink-rtnl (dpif-netlink-rtnl)?
You're right. I will remove it and submit v2. Thanks for the review.
William
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] bpf: muli prog support for cgroup-bpf
From: David Miller @ 2017-10-04 23:05 UTC (permalink / raw)
To: ast; +Cc: daniel, tj, dsa, netdev, kernel-team
In-Reply-To: <20171003055028.1294791-1-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Mon, 2 Oct 2017 22:50:20 -0700
> v1->v2:
> - fixed accidentally swapped two lines which caused static_key not going to zero
> - addressed Martin's feedback and changed prog_query to be consistent
> with verifier output: return -enospc and fill supplied buffer instead
> of just returning -enospc when buffer is too small to fit all prog_ids
>
> v1:
> cgroup-bpf use cases are getting more advanced and running only
> one program per cgroup is no longer enough. Therefore introduce
> support for attaching multiple programs per cgroup and running
> a set of effective programs.
>
> These patches introduces BPF_F_ALLOW_MULTI flag for BPF_PROG_ATTACH cmd.
> The default is still NONE and behavior of BPF_F_ALLOW_OVERRIDE flag
> is unchanged.
> The difference between three possible flags for BPF_PROG_ATTACH command:
> - NONE(default): No further bpf programs allowed in the subtree.
> - BPF_F_ALLOW_OVERRIDE: If a sub-cgroup installs some bpf program,
> the program in this cgroup yields to sub-cgroup program.
> - BPF_F_ALLOW_MULTI: If a sub-cgroup installs some bpf program,
> that cgroup program gets run in addition to the program in this cgroup.
>
> Most of the logic is in patch 1. Even when cgroup doesn't have
> any programs attached its set of effective program can be non-empty.
> To quickly execute them and avoid penalizing cgroups without
> any effective programs introduce 'struct bpf_prog_array'
> which has an optimization for cgroups with zero effective programs.
>
> Patch 2 introduces BPF_PROG_QUERY command for introspection
> Patch 3 makes verifier more strict for cgroup-bpf program types.
> Patch 4+ are tests.
>
> More details in individual patches
Looks good, series applied, thanks!
^ permalink raw reply
* [GIT PULL] ARM: SoC fixes
From: Olof Johansson @ 2017-10-04 23:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
A slightly noisy fixes request this time. Explanation below. Please merge.
Thanks!
-Olof
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to 08f8c8808c924162d8f121a7f669d5dfe67bb51a:
Merge tag 'stm32-dt-fixes-for-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into fixes (2017-10-04 10:31:00 -0700)
----------------------------------------------------------------
ARM: SoC fixes for 4.14-rc
Our first batch of fixes this release cycle, unfortunately a bit noisier
than usual. Two major groups stand out:
- Some pinctril dts/dtsi changes for stm32 due to a new driver being
merged during the merge window, and this aligns the DT contents between
the old format and the new. This could arguably be moved to the next
merge window but it also seemed relatively harmless to include now.
- Amlogic/meson had driver changes merged that required devicetree
changes to avoid functional/performance regressions. I've already
asked them to be more careful about this going forward, and making
sure drivers are compatible with older DTs when they make these kind
of changes. The platform is actively being upstreamed so there's a
few things in flight, we've seen this happen before and sometimes
it's hard to catch in time.
Besides that there is the usual mix of minor fixes.
----------------------------------------------------------------
Alexandre Belloni (1):
ARM: at91: Replace uses of virt_to_phys with __pa_symbol
Alexandre Torgue (2):
ARM: dts: stm32: Fix STMPE1600 binding on stm32429i-eval board
ARM: dts: stm32: use right pinctrl compatible for stm32f469
Arnd Bergmann (1):
ARM: defconfig: FRAMEBUFFER_CONSOLE can no longer be =m
Baruch Siach (1):
arm64: dt marvell: Fix AP806 system controller size
Eugeniy Paltsev (1):
ARC: reset: add missing DT binding documentation for HSDKv1 reset driver
Geert Uytterhoeven (1):
reset: Restrict RESET_HSDK to ARC_SOC_HSDK or COMPILE_TEST
H. Nikolaus Schaller (1):
ARM: OMAP2+: hsmmc: fix logic to call either omap_hsmmc_init or omap_hsmmc_late_init but not both
Heiko Stuebner (1):
Revert "arm64: dts: rockchip: Add basic cpu frequencies for RK3368"
Jerome Brunet (9):
ARM64: dts: meson-gx: Use correct mmc clock source 0
ARM64: dts: meson: remove cap-sd-highspeed from emmc nodes
ARM64: dts: meson: add mmc clk gate pins
ARM64: dts: meson-gxbb: nanopi-k2: add card regulator settle times
ARM64: dts: meson-gxl: libretech-cc: add card regulator settle times
ARM64: dts: meson-gxl: libretech-cc: enable high speed modes
ARM64: dts: meson-gxbb: p20x: enable sdcard UHS modes
ARM64: dts: meson-gxbb: nanopi-k2: enable sdcard UHS modes
ARM64: dts: meson-gxbb: nanopi-k2: enable sdr104 mode
Keerthy (2):
ARM: OMAP2+: dra7xx: Set OPT_CLKS_IN_RESET flag for gpio1
ARM: dts: dra7: Set a default parent to mcasp3_ahclkx_mux
Linus Walleij (1):
ARM: defconfig: update Gemini defconfig
Ludovic Desroches (2):
ARM: dts: at91: sama5d27_som1_ek: update pinmux/pinconf for LEDs and USB
ARM: dts: at91: sama5d27_som1_ek: fix typos
Nickey Yang (2):
arm64: dts: rockchip: Correct MIPI DPHY PLL clock on rk3399
arm64: dts: rockchip: add the grf clk for dw-mipi-dsi on rk3399
Nicolas Ferre (1):
ARM: dts: at91: sama5d27_som1_ek: fix USB host vbus
Olof Johansson (8):
Merge tag 'at91-fixes' of git://git.kernel.org/.../nferre/linux-at91 into fixes
Merge tag 'davinci-fixes-for-v4.14' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes
Merge tag 'reset-fixes-for-4.14' of git://git.pengutronix.de/git/pza/linux into fixes
Merge tag 'mvebu-fixes-4.14-1' of git://git.infradead.org/linux-mvebu into fixes
Merge tag 'v4.14-rockchip-dts64fixes-1' of git://git.kernel.org/.../mmind/linux-rockchip into fixes
Merge tag 'omap-for-v4.14/fixes-rc3' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'amlogic-dt64-3' of git://git.kernel.org/.../khilman/linux-amlogic into fixes
Merge tag 'stm32-dt-fixes-for-v4.14' of git://git.kernel.org/.../atorgue/stm32 into fixes
Pavel Machek (1):
ARM: dts: nokia n900: drop unneeded/undocumented parts of the dts
Russell King (1):
MAINTAINERS: add Macchiatobin maintainers entry
Sekhar Nori (1):
ARM: dts: da850-evm: add serial and ethernet aliases
Suniel Mahesh (1):
ARM: dts: am33xx: Add spi alias to match SOC schematics
Thomas Meyer (1):
ARC: reset: Only build on archs that have IOMEM
Vineet Gupta (1):
ARC: reset: remove the misleading v1 suffix all over
Yogesh Siraswar (1):
ARM: dts: am43xx-epos-evm: Remove extra CPSW EMAC entry
.../devicetree/bindings/reset/snps,hsdk-reset.txt | 28 ++
MAINTAINERS | 12 +-
arch/arm/boot/dts/am33xx.dtsi | 2 +
arch/arm/boot/dts/am43x-epos-evm.dts | 6 +-
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 19 +-
arch/arm/boot/dts/da850-evm.dts | 7 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +
arch/arm/boot/dts/omap3-n900.dts | 11 -
arch/arm/boot/dts/stm32429i-eval.dts | 5 +-
arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 343 +++++++++++++++++++++
arch/arm/boot/dts/stm32f429-disco.dts | 1 +
arch/arm/boot/dts/stm32f429-pinctrl.dtsi | 95 ++++++
arch/arm/boot/dts/stm32f429.dtsi | 297 ------------------
arch/arm/boot/dts/stm32f469-disco.dts | 1 +
arch/arm/boot/dts/stm32f469-pinctrl.dtsi | 96 ++++++
arch/arm/configs/gemini_defconfig | 3 +-
arch/arm/configs/pxa_defconfig | 2 +-
arch/arm/configs/viper_defconfig | 2 +-
arch/arm/configs/zeus_defconfig | 2 +-
arch/arm/mach-at91/pm.c | 4 +-
arch/arm/mach-omap2/hsmmc.c | 4 +-
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
.../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 10 +-
.../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 19 +-
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 12 +-
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 9 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 13 +-
.../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 10 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 39 ++-
.../dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts | 7 +-
.../dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 13 +-
.../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 10 +-
.../boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 10 +-
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 39 ++-
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 7 +-
arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts | 1 -
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 4 +-
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 72 +----
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +-
drivers/reset/Kconfig | 9 +-
drivers/reset/Makefile | 2 +-
drivers/reset/{reset-hsdk-v1.c => reset-hsdk.c} | 44 +--
include/dt-bindings/reset/snps,hsdk-reset.h | 17 +
include/dt-bindings/reset/snps,hsdk-v1-reset.h | 17 -
44 files changed, 810 insertions(+), 503 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
create mode 100644 arch/arm/boot/dts/stm32f4-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/stm32f429-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/stm32f469-pinctrl.dtsi
rename drivers/reset/{reset-hsdk-v1.c => reset-hsdk.c} (72%)
create mode 100644 include/dt-bindings/reset/snps,hsdk-reset.h
delete mode 100644 include/dt-bindings/reset/snps,hsdk-v1-reset.h
^ permalink raw reply
* [GIT PULL] ARM: SoC fixes
From: Olof Johansson @ 2017-10-04 23:05 UTC (permalink / raw)
To: torvalds; +Cc: olof, arm, linux-kernel, linux-arm-kernel
Hi Linus,
A slightly noisy fixes request this time. Explanation below. Please merge.
Thanks!
-Olof
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to 08f8c8808c924162d8f121a7f669d5dfe67bb51a:
Merge tag 'stm32-dt-fixes-for-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into fixes (2017-10-04 10:31:00 -0700)
----------------------------------------------------------------
ARM: SoC fixes for 4.14-rc
Our first batch of fixes this release cycle, unfortunately a bit noisier
than usual. Two major groups stand out:
- Some pinctril dts/dtsi changes for stm32 due to a new driver being
merged during the merge window, and this aligns the DT contents between
the old format and the new. This could arguably be moved to the next
merge window but it also seemed relatively harmless to include now.
- Amlogic/meson had driver changes merged that required devicetree
changes to avoid functional/performance regressions. I've already
asked them to be more careful about this going forward, and making
sure drivers are compatible with older DTs when they make these kind
of changes. The platform is actively being upstreamed so there's a
few things in flight, we've seen this happen before and sometimes
it's hard to catch in time.
Besides that there is the usual mix of minor fixes.
----------------------------------------------------------------
Alexandre Belloni (1):
ARM: at91: Replace uses of virt_to_phys with __pa_symbol
Alexandre Torgue (2):
ARM: dts: stm32: Fix STMPE1600 binding on stm32429i-eval board
ARM: dts: stm32: use right pinctrl compatible for stm32f469
Arnd Bergmann (1):
ARM: defconfig: FRAMEBUFFER_CONSOLE can no longer be =m
Baruch Siach (1):
arm64: dt marvell: Fix AP806 system controller size
Eugeniy Paltsev (1):
ARC: reset: add missing DT binding documentation for HSDKv1 reset driver
Geert Uytterhoeven (1):
reset: Restrict RESET_HSDK to ARC_SOC_HSDK or COMPILE_TEST
H. Nikolaus Schaller (1):
ARM: OMAP2+: hsmmc: fix logic to call either omap_hsmmc_init or omap_hsmmc_late_init but not both
Heiko Stuebner (1):
Revert "arm64: dts: rockchip: Add basic cpu frequencies for RK3368"
Jerome Brunet (9):
ARM64: dts: meson-gx: Use correct mmc clock source 0
ARM64: dts: meson: remove cap-sd-highspeed from emmc nodes
ARM64: dts: meson: add mmc clk gate pins
ARM64: dts: meson-gxbb: nanopi-k2: add card regulator settle times
ARM64: dts: meson-gxl: libretech-cc: add card regulator settle times
ARM64: dts: meson-gxl: libretech-cc: enable high speed modes
ARM64: dts: meson-gxbb: p20x: enable sdcard UHS modes
ARM64: dts: meson-gxbb: nanopi-k2: enable sdcard UHS modes
ARM64: dts: meson-gxbb: nanopi-k2: enable sdr104 mode
Keerthy (2):
ARM: OMAP2+: dra7xx: Set OPT_CLKS_IN_RESET flag for gpio1
ARM: dts: dra7: Set a default parent to mcasp3_ahclkx_mux
Linus Walleij (1):
ARM: defconfig: update Gemini defconfig
Ludovic Desroches (2):
ARM: dts: at91: sama5d27_som1_ek: update pinmux/pinconf for LEDs and USB
ARM: dts: at91: sama5d27_som1_ek: fix typos
Nickey Yang (2):
arm64: dts: rockchip: Correct MIPI DPHY PLL clock on rk3399
arm64: dts: rockchip: add the grf clk for dw-mipi-dsi on rk3399
Nicolas Ferre (1):
ARM: dts: at91: sama5d27_som1_ek: fix USB host vbus
Olof Johansson (8):
Merge tag 'at91-fixes' of git://git.kernel.org/.../nferre/linux-at91 into fixes
Merge tag 'davinci-fixes-for-v4.14' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes
Merge tag 'reset-fixes-for-4.14' of git://git.pengutronix.de/git/pza/linux into fixes
Merge tag 'mvebu-fixes-4.14-1' of git://git.infradead.org/linux-mvebu into fixes
Merge tag 'v4.14-rockchip-dts64fixes-1' of git://git.kernel.org/.../mmind/linux-rockchip into fixes
Merge tag 'omap-for-v4.14/fixes-rc3' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'amlogic-dt64-3' of git://git.kernel.org/.../khilman/linux-amlogic into fixes
Merge tag 'stm32-dt-fixes-for-v4.14' of git://git.kernel.org/.../atorgue/stm32 into fixes
Pavel Machek (1):
ARM: dts: nokia n900: drop unneeded/undocumented parts of the dts
Russell King (1):
MAINTAINERS: add Macchiatobin maintainers entry
Sekhar Nori (1):
ARM: dts: da850-evm: add serial and ethernet aliases
Suniel Mahesh (1):
ARM: dts: am33xx: Add spi alias to match SOC schematics
Thomas Meyer (1):
ARC: reset: Only build on archs that have IOMEM
Vineet Gupta (1):
ARC: reset: remove the misleading v1 suffix all over
Yogesh Siraswar (1):
ARM: dts: am43xx-epos-evm: Remove extra CPSW EMAC entry
.../devicetree/bindings/reset/snps,hsdk-reset.txt | 28 ++
MAINTAINERS | 12 +-
arch/arm/boot/dts/am33xx.dtsi | 2 +
arch/arm/boot/dts/am43x-epos-evm.dts | 6 +-
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 19 +-
arch/arm/boot/dts/da850-evm.dts | 7 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +
arch/arm/boot/dts/omap3-n900.dts | 11 -
arch/arm/boot/dts/stm32429i-eval.dts | 5 +-
arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 343 +++++++++++++++++++++
arch/arm/boot/dts/stm32f429-disco.dts | 1 +
arch/arm/boot/dts/stm32f429-pinctrl.dtsi | 95 ++++++
arch/arm/boot/dts/stm32f429.dtsi | 297 ------------------
arch/arm/boot/dts/stm32f469-disco.dts | 1 +
arch/arm/boot/dts/stm32f469-pinctrl.dtsi | 96 ++++++
arch/arm/configs/gemini_defconfig | 3 +-
arch/arm/configs/pxa_defconfig | 2 +-
arch/arm/configs/viper_defconfig | 2 +-
arch/arm/configs/zeus_defconfig | 2 +-
arch/arm/mach-at91/pm.c | 4 +-
arch/arm/mach-omap2/hsmmc.c | 4 +-
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
.../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 10 +-
.../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 19 +-
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 12 +-
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 9 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 13 +-
.../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 10 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 39 ++-
.../dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts | 7 +-
.../dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 13 +-
.../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 10 +-
.../boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 10 +-
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 39 ++-
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 7 +-
arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts | 1 -
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 4 +-
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 72 +----
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +-
drivers/reset/Kconfig | 9 +-
drivers/reset/Makefile | 2 +-
drivers/reset/{reset-hsdk-v1.c => reset-hsdk.c} | 44 +--
include/dt-bindings/reset/snps,hsdk-reset.h | 17 +
include/dt-bindings/reset/snps,hsdk-v1-reset.h | 17 -
44 files changed, 810 insertions(+), 503 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
create mode 100644 arch/arm/boot/dts/stm32f4-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/stm32f429-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/stm32f469-pinctrl.dtsi
rename drivers/reset/{reset-hsdk-v1.c => reset-hsdk.c} (72%)
create mode 100644 include/dt-bindings/reset/snps,hsdk-reset.h
delete mode 100644 include/dt-bindings/reset/snps,hsdk-v1-reset.h
^ permalink raw reply
* Re: [Part2 PATCH v5 09/31] crypto: ccp: Build the AMD secure processor driver only with AMD CPU support
From: Brijesh Singh @ 2017-10-04 23:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: brijesh.singh, x86, kvm, linux-kernel, Tom Lendacky, Gary Hook,
Herbert Xu, David S. Miller, linux-crypto
In-Reply-To: <20171004214752.imwom4slkmtgxuqr@pd.tnic>
On 10/04/2017 04:47 PM, Borislav Petkov wrote:>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>
> i.e., the first SOB is the author's and the second is yours which means,
> you've handled the patch further on, like sending it upstream, for
> example.
>
Noted, thanks
^ permalink raw reply
* Re: Extreme time jitter with suspend/resume cycles
From: Gabriel Beddingfield @ 2017-10-04 23:10 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Stephen Boyd, John Stultz, Alessandro Zummo,
Alexandre Belloni, linux-rtc, Guy Erb, hharte
In-Reply-To: <alpine.DEB.2.20.1710041931560.2406@nanos>
Hi Thomas,
Thanks for your reply!
On Wed, Oct 4, 2017 at 11:22 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> Calling things a hack which might have been thought out carefully does not
> make people more receptive.
My bad... sorry! You're right. The code in question is better than a "hack."
>> Many ARM systems provide a "persistent clock." Most of them are backed
>> by a 32kHz clock that gives good precision and makes the delta_delta
>> hack unnecessary. However, devices that only have single-second
>> precision for the persistent clock and/or are forced to use the RTC
>> (whose API only allows for single-second precision) -- they still need
>> this hack.
>
> I have no idea what you are trying to tell me. We know that there are
> systems which have a clocksource which continues to tick across
> suspend/resume.
I'm referring to read_persistent_clock64() API... which is distinct from the
CLOCK_SOURCE_SUSPEND_NONSTOP flag.
> Such clocksources can be flagged with CLOCK_SOURCE_SUSPEND_NONSTOP and the
> timekeeping resume code uses them when available instead of using the
> RTC. There are a few of them flagged as such in the kernel, but it might
...
> It's neither a problem of the timekeeping core code to select the
> appropriate clocksource for a system. That's up to the developer who
> implemented the SoC/CPU support and made a decision about rating the
> clocksource(s), which might end up selecting one which stops in suspend.
This was our first approach. However, because of some hardware
limitations we couldn't
move the system's monotonic clock to the persistent clock. They had to
be two different
clocks. (Details below.)
> Without looking at what it does, I can tell you that making it a config
> option is not going to fly. It has to be runtime discoverable as we have to
> support multi platform kernels.
OK. Here's a couple ideas...
APPROACH ONE: Use a heuristic
If read_persistent_clock64() ever returns fractional seconds (as
apposed to whole seconds), then
permanently disable the compensation.
APPROACH TWO: Use a property
Provide another weak symbol like this:
extern u64 persistent_clock_precision;
or..
void get_persistent_clock_precision(struct timespec *ts);
void get_persistent_clock_percision64(struct timespec64 *ts);
And the value returned should be, approximately, the minimum time
between clock ticks.
For clocks that only supply whole-second precision... the value should
be NSECS_PER_SEC.
For clocks that are backed by, say, a 32kHz clock... the value should be
(NSECS_PER_SEC/32768).
> Though I still want to know exactly why you think that you need some extra
> magic in the timekeeping core code. If your system has a clocksource which
> is not stopping on suspend and it lacks the flag, then this is a one liner
> patch. If there is something else, then please elaborate.
Long story short: you can't always have your low-power clock be your
monotonic/sched
clock.
The SoC we use backs the monotonic clock (sched_clock_register()) with
a counter that is
high frequency (>10 MHz) in their reference implementation. But it
does not count when the
system is in low-power mode. However, it can be configured to use a
32kHz clock that *does*
count when the system is in low-power mode. So, we started by using
this clock and setting the
CLOCK_SOURCE_SUSPEND_NONSTOP flag. It worked great... at first.
Then we found that devices would randomly experience a 36-hour time jump.
While we don't have a definitive root cause, the current theory is
that we are getting
non-atomic reads because the clock source isn't synchronized with the
the high frequency
clock (which is used for most of the digital logic on the SoC).
Therefore, we moved the monotonic/sched clock back to the high-frequency source.
Meanwhile, we can directly read the RTC clock on this system, and it
will give us 32kHz
resolution and also runs non-stop. Since reads are non-atomic, we have
to read the
registers in a loop. We used this register to implement
read_persistent_clock64().
Because we have to read the registers in a loop, it seemed unfit for use as the
monotonic/sched clock.
Thanks,
Gabe
^ permalink raw reply
* Re: [PATCH 11/25] xfs: scrub the AGI
From: Darrick J. Wong @ 2017-10-04 23:12 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-xfs
In-Reply-To: <20171004221634.GG3666@dastard>
On Thu, Oct 05, 2017 at 09:16:34AM +1100, Dave Chinner wrote:
> On Wed, Oct 04, 2017 at 11:02:04AM -0700, Darrick J. Wong wrote:
> > On Wed, Oct 04, 2017 at 05:43:33PM +1100, Dave Chinner wrote:
> > > It seems to me that we're using the superblock 0 values as the
> > > golden master because it's a mounted filesystem, and then comparing
> > > everything else against it. Maybe we should at least check a couple
> > > of secondary superblocks to see that they match the primary
> > > superblock - that way we'll have some confidence that at least
> > > things like agcount, agblocks, dblocks, etc are valid before we go
> > > any further...
> >
> > xfs_scrub_superblock does check the secondary superblock geometry
> > against whatever's in mp->m_sb, which came from sb 0.
>
> /me smacks forehead
>
> The patch is even named "scrub the backup superblocks".
>
> Perhaps it didn't sink in because they are normally called
> "secondary superblocks". My bad....
Sometimes I think I still have ext4 on the brain. :(
--D
> > > BUt maybe all we need is comment in the overall scrub description -
> > > that we're pretty much assuming that sb 0 is intact because we write
> > > what is in memory back to it and so we can simply validate
> > > everything else against the primary superblock contents...
> >
> > Correct. Since scrub is run against a mounted live filesystem we assume
> > that the mount code fully validated sb 0 and therefore we can rely on it
> > not being wrong.
> >
> > If OTOH sb 0 *is* wrong then the admin is better off running xfs_repair
> > because there's too much whirring machinery to go changing fundamental
> > geometry.
>
> Yup, that makes sense.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Can't mount array with super_total_bytes mismatch with fs_devices total_rw_bytes
From: Asif Youssuff @ 2017-10-04 23:13 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs
In-Reply-To: <7cbdb7e9-3c1b-c5cb-4ff0-4530de23f6e1@gmx.com>
On 10/04/2017 01:18 AM, Qu Wenruo wrote:
>
>
> On 2017年10月04日 12:00, Asif Youssuff wrote:
>> Thanks for the advice.
>>
>> On 10/03/2017 09:38 PM, Qu Wenruo wrote:
>>
>>
>>>>
>>>> [210017.281912] BTRFS info (device sdb): disk space caching is enabled
>>>> [210017.281915] BTRFS info (device sdb): has skinny extents
>>>> [210017.402084] BTRFS error (device sdb): super_total_bytes
>>>> 92017859088384
>>>> mismatch with fs_devices total_rw_bytes 92017859094528
>>>
>>> One of your device size is not aligned to 4K.
>>> Which is fine, but recently enhanced validation checker does not
>>> allow it.
>>> (Which should be a regression, and there is some other WARN_ON
>>> related to it)
>>>
>>>> [210017.402126] BTRFS error (device sdb): failed to read chunk tree:
>>>> -22
>>>> [210017.461473] BTRFS error (device sdb): open_ctree failed
>>>>
>>>> I've tried a few steps --
>>>>
>>>> btrfs-chunk-recover, super-recover and I have run a btrfs check
>>>> --repair on two of the disks in the array (this takes a very long
>>>> time, so I'm hoping I don't have to run this on all of the disks).
>>>>
>>>> I had run into this problem once before in the past, and I'm not
>>>> sure how I recovered from it; I may have simply rolled back the
>>>> booted kernel to escape the extra checks around this mismatch.
>>>>
>>>> I'm at a loss for ideas and am running a btrfs-image so I can also
>>>> report an issue -- I'm not sure whether 'btrfs-image -c9 -t4
>>>> /dev/sdo btrfs.image' is the right command to run if it is a
>>>> multi-device array.
>>>>
>>>> Any ideas would be helpful, and I am happy to provide further
>>>> information.
>>>>
>>>> root@ubuntu-server:~# uname -a
>>>> Linux ubuntu-server 4.14.0-041400rc2-generic #201709242031 SMP Mon
>>>> Sep 25 00:33:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> You can rollback to an earlier kernel to mount the fs.
>>>
>>> And manually find and resize the device with unaligned size:
>>>
>>> # btrfs fi show -b
>>> And check each device for its size:
>>> Label: none uuid: 839ddcfa-5701-4437-aff3-bcb2a26ae6dd
>>> Total devices 1 FS bytes used 397312
>>> devid 1 size <<10737418240>> used 2172649472 path
>>> /dev/mapper/data-btrfs
>>>
>>> If it's not align, round it down to 4K, and resize it using devid:
>>>
>>> # btrfs fi resize <devid>:<rounded_size> <mount_point>
>>>
>>> All device must be rounded. And the command should finish almost in
>>> no time.
>>
>> I was able to mount the fs using kernel version 4.4 and rounded down
>> (took the size in bytes, and rounded down to a smaller number
>> divisible by 4096).
>>
>> This is what btrfs fi show looks like now:
>>
>> asif@ubuntu-server:~$ sudo btrfs fi show --raw
>> [sudo] password for asif:
>> Label: none uuid: 48ed8a66-731d-499b-829e-dd07dd7260cc
>> Total devices 13 FS bytes used 44783241728000
>> devid 4 size 6001141571584 used 5955045097472 path /dev/sdh
>> devid 5 size 6001141571584 used 5955128983552 path /dev/sdg
>> devid 7 size 6001141571584 used 5955709960192 path /dev/sdk
>> devid 9 size 6001175126016 used 5955716186112 path /dev/sde
>> devid 10 size 6001141571584 used 5955145760768 path /dev/sdc
>> devid 11 size 8001563222016 used 7955416416256 path /dev/sdl
>> devid 12 size 6001175126016 used 5956054286336 path /dev/sdf
>> devid 14 size 8001563222016 used 7956009123840 path /dev/sdb
>> devid 15 size 8001563222016 used 7956373831680 path /dev/sdj
>> devid 17 size 8001563222016 used 6341094866944 path /dev/sdd
>> devid 18 size 8001563222016 used 7955827064832 path /dev/sdn
>> devid 20 size 8001563222016 used 7955378339840 path /dev/sdi
>> devid 21 size 8001563222016 used 7955386728448 path /dev/sdo
>>
>>>
>>> Then check if latest kernel can mount it.
>>
>> Unfortunately, the latest kernel still cannot mount it, showing the
>> same errors as before.
>>
>> [ 139.852862] BTRFS error (device sdj): super_total_bytes
>> 92017859086336 mismatch with fs_devices total_rw_bytes 92017859092480
>> [ 139.852894] BTRFS error (device sdj): failed to read chunk tree: -22
>> [ 139.916645] BTRFS error (device sdj): open_ctree failed
>
> Then the problem is btrfs doesn't update its super_total_bytes correctly.
>
> From what I can see, grow/shrink only update its delta, not
> re-calculate it.
>
> Before we have a good way to fix it in kernel, the only way is to
> manually modify the superblock to allow it pass kernel validation checker.
>
A manual edit of the superblock sounds painful unless there is good
documentation for that.
How can I follow up to get this fixed in the kernel? Do we have enough
information in this thread to create a bug on bugzilla? Should I open one?
Thanks!
> Thanks,
> Qu
>>
>>>
>>> I think it can be made as part of "btrfs check" to fix it.
>>> (Although it should be handled by kernel well)
>>>
>>> Thanks,
>>> Qu
>>
>> Hope there are some other ideas (or please correct me if I have done
>> something wrong!).
>>
>> Thanks,
>> Asif
>>
>>>
>>>>
>>>> root@ubuntu-server:~# btrfs --version
>>>> btrfs-progs v4.13.1
>>>>
>>>> root@ubuntu-server:~# btrfs fi show
>>>> Label: none uuid: 48ed8a66-731d-499b-829e-dd07dd7260cc
>>>> Total devices 13 FS bytes used 40.73TiB
>>>> devid 4 size 5.46TiB used 5.42TiB path /dev/sdo
>>>> devid 5 size 5.46TiB used 5.42TiB path /dev/sdn
>>>> devid 7 size 5.46TiB used 5.42TiB path /dev/sdc
>>>> devid 9 size 5.46TiB used 5.42TiB path /dev/sdk
>>>> devid 10 size 5.46TiB used 5.42TiB path /dev/sdj
>>>> devid 11 size 7.28TiB used 7.24TiB path /dev/sdd
>>>> devid 12 size 5.46TiB used 5.42TiB path /dev/sdm
>>>> devid 14 size 7.28TiB used 7.24TiB path /dev/sdh
>>>> devid 15 size 7.28TiB used 7.24TiB path /dev/sdb
>>>> devid 17 size 7.28TiB used 5.77TiB path /dev/sdl
>>>> devid 18 size 7.28TiB used 7.24TiB path /dev/sdf
>>>> devid 20 size 7.28TiB used 7.24TiB path /dev/sdi
>>>> devid 21 size 7.28TiB used 7.24TiB path /dev/sdg
>>>>
>>>> Thanks,
>>>> Asif
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro
From: Matthias Kaehlcke @ 2017-10-04 23:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Joe Perches, David S . Miller, Simon Horman, Dirk van der Merwe,
oss-drivers, netdev, linux-kernel, Renato Golin, Manoj Gupta,
Guenter Roeck, Doug Anderson
In-Reply-To: <20171004152203.2a4f564d@cakuba.netronome.com>
Hi Jakub,
El Wed, Oct 04, 2017 at 03:22:03PM -0700 Jakub Kicinski ha dit:
> On Wed, 4 Oct 2017 11:49:57 -0700, Matthias Kaehlcke wrote:
> > Hi Joe,
> >
> > El Wed, Oct 04, 2017 at 11:07:19AM -0700 Joe Perches ha dit:
> >
> > > On Tue, 2017-10-03 at 13:05 -0700, Matthias Kaehlcke wrote:
> > > > nfp_eth_set_bit_config() is marked as __always_inline to allow gcc to
> > > > identify the 'mask' parameter as known to be constant at compile time,
> > > > which is required to use the FIELD_GET() macro.
> > > >
> > > > The forced inlining does the trick for gcc, but for kernel builds with
> > > > clang it results in undefined symbols:
> > >
> > > Can't you use local different FIELD_PREP/FIELD_GET macros
> > > with a different name without the BUILD_BUG tests?
> > >
> > > i.e.:
> > >
> > > #define NFP_FIELD_PREP(_mask, _val) \
> > > ({ \
> > > ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \
> > > })
> > >
> > > #define NFP_FIELD_GET(_mask, _reg) \
> > > ({ \
> > > (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
> > > })
> > >
> > > Then the __always_inline can be removed from
> > > nfp_eth_set_bit_config too.
> >
> > Thanks for the suggestion. This seems a viable alternative if David
> > and the NFP owners can live without the extra checking provided by
> > __BF_FIELD_CHECK.
>
> The reason the __BF_FIELD_CHECK refuses to compile non-constant masks
> is that it will require runtime ffs on the mask, which is potentially
> costly. I would also feel quite stupid adding those macros to the nfp
> driver, given that I specifically created the bitfield.h header to not
> have to reimplement these in every driver I write/maintain.
That make sense, thanks for providing more context.
> Can you please test the patch I provided in the other reply?
With this patch there are no errors when building the kernel with
clang.
Thanks!
Matthias
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Johannes Weiner @ 2017-10-04 23:18 UTC (permalink / raw)
To: Andrew Morton
Cc: Alan Cox, Christoph Hellwig, Michal Hocko, linux-mm, linux-kernel,
kernel-team
In-Reply-To: <20171004153245.2b08d831688bb8c66ef64708@linux-foundation.org>
On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote:
> On Wed, 4 Oct 2017 14:59:06 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > This reverts commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb and
> > commit 171012f561274784160f666f8398af8b42216e1f.
> >
> > 5d17a73a2ebe ("vmalloc: back off when the current task is killed")
> > made all vmalloc allocations from a signal-killed task fail. We have
> > seen crashes in the tty driver from this, where a killed task exiting
> > tries to switch back to N_TTY, fails n_tty_open because of the vmalloc
> > failing, and later crashes when dereferencing tty->disc_data.
> >
> > Arguably, relying on a vmalloc() call to succeed in order to properly
> > exit a task is not the most robust way of doing things. There will be
> > a follow-up patch to the tty code to fall back to the N_NULL ldisc.
> >
> > But the justification to make that vmalloc() call fail like this isn't
> > convincing, either. The patch mentions an OOM victim exhausting the
> > memory reserves and thus deadlocking the machine. But the OOM killer
> > is only one, improbable source of fatal signals. It doesn't make sense
> > to fail allocations preemptively with plenty of memory in most cases.
> >
> > The patch doesn't mention real-life instances where vmalloc sites
> > would exhaust memory, which makes it sound more like a theoretical
> > issue to begin with. But just in case, the OOM access to memory
> > reserves has been restricted on the allocator side in cd04ae1e2dc8
> > ("mm, oom: do not rely on TIF_MEMDIE for memory reserves access"),
> > which should take care of any theoretical concerns on that front.
> >
> > Revert this patch, and the follow-up that suppresses the allocation
> > warnings when we fail the allocations due to a signal.
>
> You don't think they should be backported into -stables?
Good point. For this one, it makes sense to CC stable, for 4.11 and
up. The second patch is more of a fortification against potential
future issues, and probably shouldn't go into stable.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Johannes Weiner @ 2017-10-04 23:18 UTC (permalink / raw)
To: Andrew Morton
Cc: Alan Cox, Christoph Hellwig, Michal Hocko, linux-mm, linux-kernel,
kernel-team
In-Reply-To: <20171004153245.2b08d831688bb8c66ef64708@linux-foundation.org>
On Wed, Oct 04, 2017 at 03:32:45PM -0700, Andrew Morton wrote:
> On Wed, 4 Oct 2017 14:59:06 -0400 Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > This reverts commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb and
> > commit 171012f561274784160f666f8398af8b42216e1f.
> >
> > 5d17a73a2ebe ("vmalloc: back off when the current task is killed")
> > made all vmalloc allocations from a signal-killed task fail. We have
> > seen crashes in the tty driver from this, where a killed task exiting
> > tries to switch back to N_TTY, fails n_tty_open because of the vmalloc
> > failing, and later crashes when dereferencing tty->disc_data.
> >
> > Arguably, relying on a vmalloc() call to succeed in order to properly
> > exit a task is not the most robust way of doing things. There will be
> > a follow-up patch to the tty code to fall back to the N_NULL ldisc.
> >
> > But the justification to make that vmalloc() call fail like this isn't
> > convincing, either. The patch mentions an OOM victim exhausting the
> > memory reserves and thus deadlocking the machine. But the OOM killer
> > is only one, improbable source of fatal signals. It doesn't make sense
> > to fail allocations preemptively with plenty of memory in most cases.
> >
> > The patch doesn't mention real-life instances where vmalloc sites
> > would exhaust memory, which makes it sound more like a theoretical
> > issue to begin with. But just in case, the OOM access to memory
> > reserves has been restricted on the allocator side in cd04ae1e2dc8
> > ("mm, oom: do not rely on TIF_MEMDIE for memory reserves access"),
> > which should take care of any theoretical concerns on that front.
> >
> > Revert this patch, and the follow-up that suppresses the allocation
> > warnings when we fail the allocations due to a signal.
>
> You don't think they should be backported into -stables?
Good point. For this one, it makes sense to CC stable, for 4.11 and
up. The second patch is more of a fortification against potential
future issues, and probably shouldn't go into stable.
^ permalink raw reply
* [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
From: Rob Clark @ 2017-10-04 23:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <6f91564b-2458-22cb-1432-1cf560eb05c4@gmx.de>
On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> On 10/04/2017 10:54 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>>> Shell.efi uses this, and supporting color attributes makes things look
>>>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>>>> Not all colors have a perfect match, but spec just says "Devices
>>>> supporting a different number of text colors are required to emulate the
>>>> above colors to the best of the device’s capabilities".
>>>>
>>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>>> ---
>>>> include/efi_api.h | 29 +++++++++++++++++++++++++++++
>>>> lib/efi_loader/efi_console.c | 30 ++++++++++++++++++++++++++++++
>>>> 2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>>> index 87c8ffe68e..3cc1dbac2e 100644
>>>> --- a/include/efi_api.h
>>>> +++ b/include/efi_api.h
>>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>> 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>>
>>>> +#define EFI_BLACK 0x00
>>>> +#define EFI_BLUE 0x01
>>>> +#define EFI_GREEN 0x02
>>>> +#define EFI_CYAN 0x03
>>>> +#define EFI_RED 0x04
>>>> +#define EFI_MAGENTA 0x05
>>>> +#define EFI_BROWN 0x06
>>>> +#define EFI_LIGHTGRAY 0x07
>>>> +#define EFI_BRIGHT 0x08
>>>> +#define EFI_DARKGRAY 0x08
>>>> +#define EFI_LIGHTBLUE 0x09
>>>> +#define EFI_LIGHTGREEN 0x0a
>>>> +#define EFI_LIGHTCYAN 0x0b
>>>> +#define EFI_LIGHTRED 0x0c
>>>> +#define EFI_LIGHTMAGENTA 0x0d
>>>> +#define EFI_YELLOW 0x0e
>>>> +#define EFI_WHITE 0x0f
>>>> +#define EFI_BACKGROUND_BLACK 0x00
>>>> +#define EFI_BACKGROUND_BLUE 0x10
>>>> +#define EFI_BACKGROUND_GREEN 0x20
>>>> +#define EFI_BACKGROUND_CYAN 0x30
>>>> +#define EFI_BACKGROUND_RED 0x40
>>>> +#define EFI_BACKGROUND_MAGENTA 0x50
>>>> +#define EFI_BACKGROUND_BROWN 0x60
>>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>
>>> Will we ever use these constants?
>>>
>>
>> possibly not, but it is useful to understand what is going on with
>> efi->ansi mapping, so I would prefer to keep them.
>>
>>>
>>> Where are the comments explaining the defines below?
>>>
>>>> +
>>>> +#define EFI_ATTR_FG(attr) ((attr) & 0x0f)
>>>
>>> This saves 8 entries in the table below.
>>> +#define EFI_ATTR_FG(attr) ((attr) & 0x07)
>>>
>>>> +#define EFI_ATTR_BG(attr) (((attr) >> 4) & 0x7)
>>>
>>> Add
>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>
>>>> +
>>>> struct efi_simple_text_output_protocol {
>>>> void *reset;
>>>> efi_status_t (EFIAPI *output_string)(
>>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>>> index 2e13fdc096..fcd65ca488 100644
>>>> --- a/lib/efi_loader/efi_console.c
>>>> +++ b/lib/efi_loader/efi_console.c
>>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>>> return EFI_EXIT(EFI_SUCCESS);
>>>> }
>>>>
>>>> +static const struct {
>>>> + unsigned fg;
>>>> + unsigned bg;
>>>> +} color[] = {
>>>> + { 30, 40 }, /* 0: black */
>>>> + { 34, 44 }, /* 1: blue */
>>>> + { 32, 42 }, /* 2: green */
>>>> + { 36, 46 }, /* 3: cyan */
>>>> + { 31, 41 }, /* 4: red */
>>>> + { 35, 45 }, /* 5: magenta */
>>>> + { 30, 40 }, /* 6: brown, map to black */
>>>
>>> This should be { 33, 43 }
>>>
>>>> + { 37, 47 }, /* 7: light grey, map to white */
>>>
>>> The entries below are redundant.
>>>
>>>> + { 37, 47 }, /* 8: bright, map to white */
>>>> + { 34, 44 }, /* 9: light blue, map to blue */
>>>> + { 32, 42 }, /* A: light green, map to green */
>>>> + { 36, 46 }, /* B: light cyan, map to cyan */
>>>> + { 31, 41 }, /* C: light red, map to red */
>>>> + { 35, 45 }, /* D: light magenta, map to magenta */
>>>> + { 33, 43 }, /* E: yellow */
>>>> + { 37, 47 }, /* F: white */
>>>> +};
>>>> +
>>
>> I'm not totally convinced about mapping extra colors that UEFI defines
>> to bold.. unless you have some example of prior-art for this on other
>> platforms.
>
> See
> Standard ECMA-48 - Control Functions for Coded Character Sets
> chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION
>
> 1 - bold or increased intensity
> 22 - normal colour or normal intensity (neither bold nor faint)
>
> You can easily experiment in your bash shell like this:
>
> printf "\x1b[1;32;40m bold \x1b[22;32;40m normal\x1b[22;39;49m\n";
>
> You will find that "bold" prints bold and bright in the KDE konsole and
> xterm.
but I think we don't want (potential) font changes, just color changes..
if you can find the code in edk2 that does this, I guess it would be a
reasonable precedent to follow.. but if not I wanted to avoid things
that might be specific to particular terminal emulators, since I
wasn't really looking forward to testing them all. Otherwise I'd just
rely on the extension that allowed 256 colors..
BR,
-R
> Using colors 90-97 as foreground colors produces only bright but not
> bold in the KDE konsole and xterm:
>
> printf "\x1b[92;40m bold \x1b[32;40m normal\x1b[22;39;49m\n";
>
> But these codes are not defined in ECMA-48.
>
> Best regards
>
> Heinrich
>
^ permalink raw reply
* [xen-unstable-smoke test] 114021: regressions - FAIL
From: osstest service owner @ 2017-10-04 23:20 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 114021 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114021/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 113972
build-armhf 6 xen-build fail REGR. vs. 113972
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 1 build-check(1) blocked n/a
version targeted for testing:
xen 72b0c19a7040ab8446f16578b094fec8703f8095
baseline version:
xen dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Last test of basis 113972 2017-10-03 21:02:43 Z 1 days
Failing since 113979 2017-10-04 00:10:13 Z 0 days 15 attempts
Testing same since 114015 2017-10-04 18:01:26 Z 0 days 3 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Bhupinder Thakur <bhupinder.thakur@linaro.org>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Julien Grall <julien.grall@arm.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Stefano Stabellini <sstabellini@kernel.org>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 524 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options
From: Daniel Micay @ 2017-10-04 23:21 UTC (permalink / raw)
To: Roberts, William C, Linus Torvalds, Jordan Glover
Cc: Tobin C. Harding, Greg KH, Petr Mladek, Joe Perches, Ian Campbell,
Sergey Senozhatsky, kernel-hardening@lists.openwall.com,
Catalin Marinas, Will Deacon, Steven Rostedt, Chris Fries,
Dave Weinstein
In-Reply-To: <476DC76E7D1DF2438D32BFADF679FC563EAF4F29@ORSMSX103.amr.corp.intel.com>
On Wed, 2017-10-04 at 21:58 +0000, Roberts, William C wrote:
> > -----Original Message-----
> > From: linus971@gmail.com [mailto:linus971@gmail.com] On Behalf Of
> > Linus
> > Torvalds
> > Sent: Wednesday, October 4, 2017 12:19 PM
> > To: Jordan Glover <Golden_Miller83@protonmail.ch>
> > Cc: Tobin C. Harding <me@tobin.cc>; Greg KH <gregkh@linuxfoundation.
> > org>;
> > Petr Mladek <pmladek@suse.com>; Joe Perches <joe@perches.com>; Ian
> > Campbell <ijc@hellion.org.uk>; Sergey Senozhatsky
> > <sergey.senozhatsky@gmail.com>; kernel-hardening@lists.openwall.com;
> > Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> > <will.deacon@arm.com>; Steven Rostedt <rostedt@goodmis.org>;
> > Roberts,
> > William C <william.c.roberts@intel.com>; Chris Fries <cfries@google.
> > com>; Dave
> > Weinstein <olorin@google.com>
> > Subject: Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer
> > filter
> > options
> >
> > On Wed, Oct 4, 2017 at 11:58 AM, Jordan Glover
> > <Golden_Miller83@protonmail.ch> wrote:
> > > If we knew where those leaks are hiding they will be fixed
> > > already.
> > > The only thing we knew is that bugs/leaks are there. It's always
> > > better to just fix all the code but it isn't realistic.
> >
> > Honestly, what's the difference between setting kptr_restrict to 4
> > and just using
> > a sed-script (or maybe some coccinelle) to remove all existing plain
> > %p users?
>
> I can already see the hate filled irate response I'll get to this
> statement, thankfully I will
> be away not caring.
>
> The kernel proper is in a place where it can attempt to defend itself
> against stupidity, either in
> tree or out of tree. Will it stop everything? Obviously not, like you
> said %x or disabling.
>
> I agree with you 100% kptr restrict is odd, and I don't think anyone
> should have had to opt in to be
> cleansed via kptr_restrict value via %pK. Opt-in never works. One nice
> thing now, is that checkpatch
> has checking of %p usages and warns.
>
> As far as broken things, I can't comment on desktop systems where I
> think it's harder to make that claim.
> I see value in embedded systems where I am shipping the whole image,
> So I know when/what will
> break.
>
> If this was in-tree, Android would be setting this to 4 immediately
> FWIW.
It's already shipping on Pixel phones in production as of Android 8.0,
but they didn't pull it into the common kernel LTS branches yet:
https://android.googlesource.com/kernel/msm.git/+/00e1c16fbac282b99a769b939dd215cbdc775ecb%5E%21/#F0
Google backports many KSPP changes to their LTS kernels and they aren't
limiting that to changes that are already upstream. It can all just be
dropped without impacting app compatibility so it doesn't matter if the
finalized upstream approach ends up being different.
It's a similar situation to perf_event_paranoid=3 which is mandatory for
all Android devices since the August 2016 security patch despite being
rejected upstream. There's a test checking for it and integration into
the profiling tools which know how to turn it back down via the USB
debugging shell (ADB). Debian had perf_event_paranoid=3 even earlier so
it's on the vast majority of Linux devices already.
They just end up being permanent downstream patches if they're rejected
without providing an alternative on par with it.
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-net-queue:dev-queue] BUILD SUCCESS 9cb2eb6a0c48c0f45f6f69121ddca4b52db1f317
From: kbuild test robot @ 2017-10-04 23:21 UTC (permalink / raw)
To: intel-wired-lan
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git dev-queue
9cb2eb6a0c48c0f45f6f69121ddca4b52db1f317 i40e: Fix memory leak related filter programming status
elapsed time: 87m
configs tested: 158
The following configs have been built successfully.
More configs may be tested in the coming days.
m68k allnoconfig
powerpc icon_defconfig
xtensa nommu_kc705_defconfig
arm s3c2410_defconfig
powerpc storcenter_defconfig
sh sh7763rdp_defconfig
i386 randconfig-c0-10050537
arm mv78xx0_defconfig
arm vt8500_v6_v7_defconfig
sh sh2007_defconfig
x86_64 randconfig-in0-10050609
blackfin BF527-TLL6527M_defconfig
blackfin BF533-EZKIT_defconfig
sh titan_defconfig
i386 randconfig-x013-201740
i386 randconfig-x014-201740
i386 randconfig-x015-201740
i386 randconfig-x019-201740
i386 randconfig-x011-201740
i386 randconfig-x018-201740
i386 randconfig-x010-201740
i386 randconfig-x017-201740
i386 randconfig-x012-201740
i386 randconfig-x016-201740
i386 randconfig-n0-201740
arm multi_v7_defconfig
blackfin BF538-EZKIT_defconfig
sh se7712_defconfig
x86_64 kexec
x86_64 rhel
x86_64 rhel-7.2
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
i386 allmodconfig
i386 randconfig-a0-201740
i386 randconfig-a1-201740
x86_64 randconfig-s0-10050558
x86_64 randconfig-s1-10050558
x86_64 randconfig-s2-10050558
frv defconfig
mn10300 asb2364_defconfig
openrisc or1ksim_defconfig
tile tilegx_defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 randconfig-x018-201740
x86_64 randconfig-x011-201740
x86_64 randconfig-x012-201740
x86_64 randconfig-x019-201740
x86_64 randconfig-x013-201740
x86_64 randconfig-x017-201740
x86_64 randconfig-x015-201740
x86_64 randconfig-x014-201740
x86_64 randconfig-x016-201740
x86_64 randconfig-x010-201740
i386 allnoconfig
i386 defconfig
i386 alldefconfig
x86_64 randconfig-i0-201740
arm moxart_defconfig
arm xcep_defconfig
m68k mvme16x_defconfig
score spct6600_defconfig
i386 randconfig-i0-201740
i386 randconfig-i1-201740
x86_64 randconfig-b0-10050605
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
arm u8500_defconfig
mips capcella_defconfig
powerpc allyesconfig
x86_64 randconfig-u0-10050556
i386 tinyconfig
arm h3600_defconfig
sh rsk7203_defconfig
x86_64 randconfig-ne0-10050600
mips bmips_be_defconfig
openrisc allyesconfig
powerpc sbc834x_defconfig
sh allnoconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
i386 allyesconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
i386 randconfig-sb0-10050618
i386 randconfig-x001-201740
i386 randconfig-x008-201740
i386 randconfig-x004-201740
i386 randconfig-x003-201740
i386 randconfig-x002-201740
i386 randconfig-x006-201740
i386 randconfig-x007-201740
i386 randconfig-x009-201740
i386 randconfig-x000-201740
i386 randconfig-x005-201740
x86_64 allmodconfig
x86_64 randconfig-x001-201740
x86_64 randconfig-x000-201740
x86_64 randconfig-x004-201740
x86_64 randconfig-x008-201740
x86_64 randconfig-x006-201740
x86_64 randconfig-x007-201740
x86_64 randconfig-x005-201740
x86_64 randconfig-x009-201740
x86_64 randconfig-x003-201740
x86_64 randconfig-x002-201740
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
m32r m32104ut_defconfig
m32r mappi3.smp_defconfig
m32r opsput_defconfig
m32r usrv_defconfig
nios2 10m50_defconfig
xtensa common_defconfig
xtensa iss_defconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm64 defconfig
x86_64 randconfig-ws0-10050320
i386 randconfig-x074-201740
i386 randconfig-x071-201740
i386 randconfig-x076-201740
i386 randconfig-x077-201740
i386 randconfig-x073-201740
i386 randconfig-x079-201740
i386 randconfig-x072-201740
i386 randconfig-x078-201740
i386 randconfig-x075-201740
i386 randconfig-x070-201740
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
x86_64 randconfig-r0-10050501
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
Thanks,
Fengguang
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Stephen Boyd @ 2017-10-04 23:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGvHfKfuVRVoZvGkKKzLwRLvwJHJqBdbPUtwBY8_rH6V-w@mail.gmail.com>
On 10/04, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 6:09 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 10/04, Rob Clark wrote:
> >> If we managed to get this in before the 4.14 LTS I might feel
> >> differently. But afterwards, totally not. :-(
> >>
> >
> > How do you install dtbs onto your device? Should be simple enough
> > to run 'mv' on the new filename to the old one?
> >
>
> it is part of the kernel package
Are you copying the file out of the arch/arm64/boot/dts
directory? Or you're using dtbs_install rule?
> but fixing it in the distro means fixing it in *every* distro..
That assumes every distro has a bootloader that's looking for one
file name vs. the other. And that the distro hasn't updated the
bootloader to pick a different name.
>
> if we are going for a workaround, then it should be the kernel
> installing a symlink. Not every distro having to fix things up in the
> same way for one particular board.
There was a discussion about this years ago when the dtbs_install
rule was introduced to the kernel makefiles[1]. Maybe the
sentiment has changed, but it seems that people involved in that
thread didn't consider the filename an ABI. Also, take a look at
commit f4d4ffc03efc ("kbuild: dtbs_install: new make target")
where it says:
"Removed option to call external script. Copying the files should
be sufficient and a build system can post-process the install
directory. Despite the fact an external script is used for
installing the kernel, I don't think that is a pattern that
should be encouraged. I would rather see buildroot type tools
post process the install directory to rename or move dtb files
after installing to a staging directory."
which makes it look like the distro installation scripts would
rename things if desired.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/210562.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Stephen Boyd @ 2017-10-04 23:21 UTC (permalink / raw)
To: Rob Clark
Cc: Nicolas Dechesne, Srinivas Kandagatla, Linus Walleij,
linux-arm-kernel@lists.infradead.org, linux-arm-msm, Andy Gross,
David Brown, Bjorn Andersson, linux-soc, Alexander Graf
In-Reply-To: <CAF6AEGvHfKfuVRVoZvGkKKzLwRLvwJHJqBdbPUtwBY8_rH6V-w@mail.gmail.com>
On 10/04, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 6:09 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 10/04, Rob Clark wrote:
> >> If we managed to get this in before the 4.14 LTS I might feel
> >> differently. But afterwards, totally not. :-(
> >>
> >
> > How do you install dtbs onto your device? Should be simple enough
> > to run 'mv' on the new filename to the old one?
> >
>
> it is part of the kernel package
Are you copying the file out of the arch/arm64/boot/dts
directory? Or you're using dtbs_install rule?
> but fixing it in the distro means fixing it in *every* distro..
That assumes every distro has a bootloader that's looking for one
file name vs. the other. And that the distro hasn't updated the
bootloader to pick a different name.
>
> if we are going for a workaround, then it should be the kernel
> installing a symlink. Not every distro having to fix things up in the
> same way for one particular board.
There was a discussion about this years ago when the dtbs_install
rule was introduced to the kernel makefiles[1]. Maybe the
sentiment has changed, but it seems that people involved in that
thread didn't consider the filename an ABI. Also, take a look at
commit f4d4ffc03efc ("kbuild: dtbs_install: new make target")
where it says:
"Removed option to call external script. Copying the files should
be sufficient and a build system can post-process the install
directory. Despite the fact an external script is used for
installing the kernel, I don't think that is a pattern that
should be encouraged. I would rather see buildroot type tools
post process the install directory to rename or move dtb files
after installing to a staging directory."
which makes it look like the distro installation scripts would
rename things if desired.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/210562.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Johannes Weiner @ 2017-10-04 23:21 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: akpm, alan, hch, mhocko, linux-mm, linux-kernel, kernel-team
In-Reply-To: <201710050642.JJI34818.QFSHJOMOtFOLFV@I-love.SAKURA.ne.jp>
On Thu, Oct 05, 2017 at 06:42:38AM +0900, Tetsuo Handa wrote:
> Johannes Weiner wrote:
> > On Thu, Oct 05, 2017 at 05:49:43AM +0900, Tetsuo Handa wrote:
> > > On 2017/10/05 3:59, Johannes Weiner wrote:
> > > > But the justification to make that vmalloc() call fail like this isn't
> > > > convincing, either. The patch mentions an OOM victim exhausting the
> > > > memory reserves and thus deadlocking the machine. But the OOM killer
> > > > is only one, improbable source of fatal signals. It doesn't make sense
> > > > to fail allocations preemptively with plenty of memory in most cases.
> > >
> > > By the time the current thread reaches do_exit(), fatal_signal_pending(current)
> > > should become false. As far as I can guess, the source of fatal signal will be
> > > tty_signal_session_leader(tty, exit_session) which is called just before
> > > tty_ldisc_hangup(tty, cons_filp != NULL) rather than the OOM killer. I don't
> > > know whether it is possible to make fatal_signal_pending(current) true inside
> > > do_exit() though...
> >
> > It's definitely not the OOM killer, the memory situation looks fine
> > when this happens. I didn't look closer where the signal comes from.
> >
>
> Then, we could check tsk_is_oom_victim() instead of fatal_signal_pending().
The case for this patch didn't seem very strong to beging with, and
since it's causing problems a simple revert makes more sense than an
attempt to fine-tune it.
Generally, we should leave it to the page allocator to handle memory
reserves, not annotate random alloc_page() callsites.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Johannes Weiner @ 2017-10-04 23:21 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: akpm, alan, hch, mhocko, linux-mm, linux-kernel, kernel-team
In-Reply-To: <201710050642.JJI34818.QFSHJOMOtFOLFV@I-love.SAKURA.ne.jp>
On Thu, Oct 05, 2017 at 06:42:38AM +0900, Tetsuo Handa wrote:
> Johannes Weiner wrote:
> > On Thu, Oct 05, 2017 at 05:49:43AM +0900, Tetsuo Handa wrote:
> > > On 2017/10/05 3:59, Johannes Weiner wrote:
> > > > But the justification to make that vmalloc() call fail like this isn't
> > > > convincing, either. The patch mentions an OOM victim exhausting the
> > > > memory reserves and thus deadlocking the machine. But the OOM killer
> > > > is only one, improbable source of fatal signals. It doesn't make sense
> > > > to fail allocations preemptively with plenty of memory in most cases.
> > >
> > > By the time the current thread reaches do_exit(), fatal_signal_pending(current)
> > > should become false. As far as I can guess, the source of fatal signal will be
> > > tty_signal_session_leader(tty, exit_session) which is called just before
> > > tty_ldisc_hangup(tty, cons_filp != NULL) rather than the OOM killer. I don't
> > > know whether it is possible to make fatal_signal_pending(current) true inside
> > > do_exit() though...
> >
> > It's definitely not the OOM killer, the memory situation looks fine
> > when this happens. I didn't look closer where the signal comes from.
> >
>
> Then, we could check tsk_is_oom_victim() instead of fatal_signal_pending().
The case for this patch didn't seem very strong to beging with, and
since it's causing problems a simple revert makes more sense than an
attempt to fine-tune it.
Generally, we should leave it to the page allocator to handle memory
reserves, not annotate random alloc_page() callsites.
^ permalink raw reply
* [Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.
From: bugzilla-daemon @ 2017-10-04 23:22 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-96868-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 1165 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=96868
--- Comment #32 from Markus-Germann@web.de ---
I wanted to add a comment, because I'm also affected with a slightly different
setup then most of the users that posted here.
I have a Radeon R9 390, use an up-to-date Arch Linux (Kernel 4.13.3-1-ARCH with
xf86-video-amdgpu 1.4.0) but with only a 60Hz screen with therefore a 4K/HiDPI
screen (resolution 3840x2160).
I also have lots of flickering and artefacts.
The problem is solved setting the power level to high, but as it raises the
temps from 50/51 to more then 60°C with the electricity consumption and cooler
going up it's not an option for me.
In low it flickers even more then in auto.
Using the manual setting however (that Andy Furniss mentioned in comment 15
from 2017-05-11 13:01:39 UTC) the problem is solved, the flickerin/tearing and
artifacting gone and the temperature seems to stay like before. (Thanks a lot
for that, Andy!)
Is it possible to make use of that solution to release it upstream?
Thanks for all the work and effort, by the way!
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2137 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [U-Boot] [PATCH] ARM: SPL: FIT: fix DTC warnings on FIT generation
From: Andre Przywara @ 2017-10-04 23:24 UTC (permalink / raw)
To: u-boot
Newer versions of the device tree compiler (rightfully) complain about
mismatches between attributed node names (name@<addr>) and a missing
reg property in that node.
Adjust the FIT build script for 64-bit Allwinner boards to remove the
bogus addresses from the node names and avoid the warnings.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
board/sunxi/mksunxi_fit_atf.sh | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
index b1d6e0e16a..36abe9efed 100755
--- a/board/sunxi/mksunxi_fit_atf.sh
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -21,7 +21,7 @@ cat << __HEADER_EOF
#address-cells = <1>;
images {
- uboot at 1 {
+ uboot {
description = "U-Boot (64-bit)";
data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
@@ -29,7 +29,7 @@ cat << __HEADER_EOF
compression = "none";
load = <0x4a000000>;
};
- atf at 1 {
+ atf {
description = "ARM Trusted Firmware";
data = /incbin/("$BL31");
type = "firmware";
@@ -44,7 +44,7 @@ cnt=1
for dtname in $*
do
cat << __FDT_IMAGE_EOF
- fdt@$cnt {
+ fdt_$cnt {
description = "$(basename $dtname .dtb)";
data = /incbin/("$dtname");
type = "flat_dt";
@@ -57,7 +57,7 @@ done
cat << __CONF_HEADER_EOF
};
configurations {
- default = "config at 1";
+ default = "config_1";
__CONF_HEADER_EOF
@@ -65,11 +65,11 @@ cnt=1
for dtname in $*
do
cat << __CONF_SECTION_EOF
- config@$cnt {
+ config_$cnt {
description = "$(basename $dtname .dtb)";
- firmware = "uboot at 1";
- loadables = "atf@1";
- fdt = "fdt@$cnt";
+ firmware = "uboot";
+ loadables = "atf";
+ fdt = "fdt_$cnt";
};
__CONF_SECTION_EOF
cnt=$((cnt+1))
--
2.14.1
^ permalink raw reply related
* [Intel-wired-lan] [jkirsher-net-queue:dev-queue] BUILD SUCCESS 86eeccd1d8aa5f27e56d0575c9f4dea2c6a78ad4
From: kbuild test robot @ 2017-10-04 23:25 UTC (permalink / raw)
To: intel-wired-lan
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git dev-queue
86eeccd1d8aa5f27e56d0575c9f4dea2c6a78ad4 e1000: fix race condition between e1000_down() and e1000_watchdog
elapsed time: 141m
configs tested: 138
The following configs have been built successfully.
More configs may be tested in the coming days.
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
i386 tinyconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
i386 randconfig-x013-201740
i386 randconfig-x014-201740
i386 randconfig-x015-201740
i386 randconfig-x019-201740
i386 randconfig-x011-201740
i386 randconfig-x018-201740
i386 randconfig-x010-201740
i386 randconfig-x017-201740
i386 randconfig-x012-201740
i386 randconfig-x016-201740
blackfin BF526-EZBRD_defconfig
blackfin BF533-EZKIT_defconfig
blackfin BF561-EZKIT-SMP_defconfig
blackfin TCM-BF537_defconfig
cris etrax-100lx_v2_defconfig
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
i386 allmodconfig
arm allmodconfig
arm arm5
arm arm67
arm imx_v6_v7_defconfig
arm ixp4xx_defconfig
arm mvebu_v7_defconfig
arm omap2plus_defconfig
arm sa1100
arm samsung
arm sh
arm tegra_defconfig
arm64 alldefconfig
arm64 allmodconfig
frv defconfig
mn10300 asb2364_defconfig
openrisc or1ksim_defconfig
tile tilegx_defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 randconfig-x018-201740
x86_64 randconfig-x011-201740
x86_64 randconfig-x012-201740
x86_64 randconfig-x019-201740
x86_64 randconfig-x013-201740
x86_64 randconfig-x017-201740
x86_64 randconfig-x015-201740
x86_64 randconfig-x014-201740
x86_64 randconfig-x016-201740
x86_64 randconfig-x010-201740
i386 alldefconfig
i386 allnoconfig
i386 defconfig
x86_64 rhel
x86_64 rhel-7.2
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
i386 randconfig-i0-201740
i386 randconfig-i1-201740
x86_64 allmodconfig
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
m32r m32104ut_defconfig
m32r mappi3.smp_defconfig
m32r opsput_defconfig
m32r usrv_defconfig
nios2 10m50_defconfig
score spct6600_defconfig
xtensa common_defconfig
xtensa iss_defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
i386 randconfig-x001-201740
i386 randconfig-x008-201740
i386 randconfig-x004-201740
i386 randconfig-x003-201740
i386 randconfig-x002-201740
i386 randconfig-x006-201740
i386 randconfig-x007-201740
i386 randconfig-x009-201740
i386 randconfig-x000-201740
i386 randconfig-x005-201740
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
x86_64 randconfig-x001-201740
x86_64 randconfig-x000-201740
x86_64 randconfig-x004-201740
x86_64 randconfig-x008-201740
x86_64 randconfig-x006-201740
x86_64 randconfig-x007-201740
x86_64 randconfig-x005-201740
x86_64 randconfig-x009-201740
x86_64 randconfig-x003-201740
x86_64 randconfig-x002-201740
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm64 defconfig
i386 randconfig-x074-201740
i386 randconfig-x071-201740
i386 randconfig-x076-201740
i386 randconfig-x077-201740
i386 randconfig-x073-201740
i386 randconfig-x079-201740
i386 randconfig-x072-201740
i386 randconfig-x078-201740
i386 randconfig-x075-201740
i386 randconfig-x070-201740
Thanks,
Fengguang
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.