[lkp] [kallsyms] 06862f34f6: BUG: unable to handle kernel NULL pointer dereference at (null)
FYI, we noticed the below changes on
https://git.linaro.org/people/ard.biesheuvel/linux-arm kallsyms-text-relative
commit 06862f34f614bb6ff6a9fc9c4b0d849e2ee2018d ("kallsyms: add support for
relative offsets in kallsyms address table")
+---+++
| | 30f05309bd |
06862f34f6 |
+---+++
| boot_successes| 0 | 0
|
| boot_failures | 6 | 8
|
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 4 |
|
| BUG:kernel_test_oversize | 2 |
|
| BUG:unable_to_handle_kernel | 0 | 8
|
+---+++
[0.568228] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[0.568971] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[0.569835] CPU: Intel Xeon E312xx (Sandy Bridge) (family: 0x6, model: 0x2a,
stepping: 0x1)
[0.598441] BUG: unable to handle kernel NULL pointer dereference at
(null)
[0.599646] IP:
[0.599884] BUG: unable to handle kernel NULL pointer dereference at
(null)
[0.610184] IP:
Elapsed time: 10
qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel
/pkg/linux/x86_64-randconfig-s4-01220217/gcc-5/06862f34f614bb6ff6a9fc9c4b0d849e2ee2018d/vmlinuz-4.4.0-10063-g06862f34
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-62/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-randconfig-s4-01220217-06862f34f614bb6ff6a9fc9c4b0d849e2ee2018d-20160122-39812-uowsx2-0.yaml
ARCH=x86_64 kconfig=x86_64-randconfig-s4-01220217
branch=linux-devel/devel-spot-201601220143
commit=06862f34f614bb6ff6a9fc9c4b0d849e2ee2018d
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s4-01220217/gcc-5/06862f34f614bb6ff6a9fc9c4b0d849e2ee2018d/vmlinuz-4.4.0-10063-g06862f34
max_uptime=600
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-randconfig-s4-01220217/gcc-5/06862f34f614bb6ff6a9fc9c4b0d849e2ee2018d/0
LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw
ip=vm-kbuild-yocto-x86_64-62::dhcp drbd.minor_count=8' -initrd
/fs/sdg1/initrd-vm-kbuild-yocto-x86_64-62 -m 320 -smp 1 -device
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog
i6300esb -rtc base=localtime -drive
file=/fs/sdg1/disk0-vm-kbuild-yocto-x86_64-62,media=disk,if=virtio -pidfile
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-62 -serial
file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-62 -daemonize -display none
-monitor null
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CO
Re: [PATCH v2] mmc: dw_mmc: remove DW_MCI_QUIRK_BROKEN_CARD_DETECTION quirk
Hi, Shawn.
On 01/21/2016 03:52 PM, Shawn Lin wrote:
> dw_mmc already use mmc_of_parse to get "broken-cd" property,
> but it considered "broken-cd" to be a quirk in its driver. We
> don't need this quirk here, and just take what we need from
> mmc->caps.
I have reverted the previous version, this version looks good to me.
I will apply this.
With Exynos SoCs,
Tested-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Shawn Lin
>
> ---
>
> Changes in v2:
> - fix wrong using of cur_slot
>
> drivers/mmc/host/dw_mmc.c | 35 ++-
> include/linux/mmc/dw_mmc.h | 4 +---
> 2 files changed, 11 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 7128351..96f173b 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1450,12 +1450,11 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> {
> int present;
> struct dw_mci_slot *slot = mmc_priv(mmc);
> - struct dw_mci_board *brd = slot->host->pdata;
> struct dw_mci *host = slot->host;
> int gpio_cd = mmc_gpio_get_cd(mmc);
>
> /* Use platform get_cd function, else try onboard card detect */
> - if ((brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION) ||
> + if ((mmc->caps & MMC_CAP_NEEDS_POLL) ||
> (mmc->caps & MMC_CAP_NONREMOVABLE))
> present = 1;
> else if (!IS_ERR_VALUE(gpio_cd))
> @@ -2840,23 +2839,13 @@ static void dw_mci_dto_timer(unsigned long arg)
> }
>
> #ifdef CONFIG_OF
> -static struct dw_mci_of_quirks {
> - char *quirk;
> - int id;
> -} of_quirks[] = {
> - {
> - .quirk = "broken-cd",
> - .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
> - },
> -};
> -
> static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
> {
> struct dw_mci_board *pdata;
> struct device *dev = host->dev;
> struct device_node *np = dev->of_node;
> const struct dw_mci_drv_data *drv_data = host->drv_data;
> - int idx, ret;
> + int ret;
> u32 clock_frequency;
>
> pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> @@ -2871,11 +2860,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
> dw_mci *host)
> pdata->num_slots = 1;
> }
>
> - /* get quirks */
> - for (idx = 0; idx < ARRAY_SIZE(of_quirks); idx++)
> - if (of_get_property(np, of_quirks[idx].quirk, NULL))
> - pdata->quirks |= of_quirks[idx].id;
> -
> if (of_property_read_u32(np, "fifo-depth", &pdata->fifo_depth))
> dev_info(dev,
>"fifo-depth property not found, using value of FIFOTH
> register as default\n");
> @@ -2908,18 +2892,19 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
> dw_mci *host)
>
> static void dw_mci_enable_cd(struct dw_mci *host)
> {
> - struct dw_mci_board *brd = host->pdata;
> unsigned long irqflags;
> u32 temp;
> int i;
> + struct dw_mci_slot *slot;
>
> - /* No need for CD if broken card detection */
> - if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> - return;
> -
> - /* No need for CD if all slots have a non-error GPIO */
> + /*
> + * No need for CD if all slots have a non-error GPIO
> + * as well as broken card detection is found.
> + */
> for (i = 0; i < host->num_slots; i++) {
> - struct dw_mci_slot *slot = host->slot[i];
> + slot = host->slot[i];
> + if (slot->mmc->caps & MMC_CAP_NEEDS_POLL)
> + return;
>
> if (IS_ERR_VALUE(mmc_gpio_get_cd(slot->mmc)))
> break;
> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
> index 89df7ab..250d822 100644
> --- a/include/linux/mmc/dw_mmc.h
> +++ b/include/linux/mmc/dw_mmc.h
> @@ -235,10 +235,8 @@ struct dw_mci_dma_ops {
> };
>
> /* IP Quirks/flags. */
> -/* Unreliable card detection */
> -#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(0)
> /* Timer for broken data transfer over scheme */
> -#define DW_MCI_QUIRK_BROKEN_DTO BIT(1)
> +#define DW_MCI_QUIRK_BROKEN_DTO BIT(0)
>
> struct dma_pdata;
>
>
Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination
On 2016/1/22 0:35, rkrc...@redhat.com wrote: 2016-01-21 13:44+0800, Yang Zhang: On 2016/1/21 13:41, Wu, Feng wrote: From: Yang Zhang [mailto:yang.zhang...@gmail.com] We may have different understanding on PI mode. My understanding is if we set the IRTE to PI format, than the subsequent interrupt will be handled in PI mode. multi-cast and broadcast interrupts cannot be injected to guest directly but it doesn't mean cannot be handled in PI mode. As i said, we can handle it in wake up vector or via other approach.But it is much complexity. KVM has to intercept the interrupt, so we'd need to trigger a deferred work from the notification handler to send the multicast. Reusing existing PI vectors would mean slowing them down, so we should define a new PI notification vector just for this purpose, which would be confusing in /proc/interrupts anyway. On top of that, we'd need to define new PIRR array(s) and create unique PID for every IRTE, to avoid parsing those PIRR arrays as the vector is stored in IRTE ... it's going a bit too far, I guess. Not so complicated. We can reuse the wake up vector and check whether the interrupt is multicast when one of destination vcpu handles it. If it is multicast, then also notifies other vcpus. It is totally handed in PI mode and we already have the wakeup vector in /proc/interrupts. For the multicast/broastcast, we cannot set the related IRTE in PI mode, since we cannot set only one destination in IRTE. If an interrupt is for multiple destination, how can you use VT-d PI to injection it to all the destinations? You may still not get my point. Anyway, it doesn't matter. Rollback to legacy mode still is the best choice so far. I think we can't do much better than we do now. -- best regards yang
Re: [RFC PATCH v2] Add IPI entry for CPU UP
On 21 January 2016 at 18:51, Mark Rutland wrote: > On Thu, Jan 21, 2016 at 04:48:57PM +0800, Zhaoyang Huang wrote: >> Hi Mark, > > Hi, > >> Do you have any suggestion on how to sync the GIC operation from >> kernel and psci parallelly? Thanks! > > I'm not sure what you mean. > > What problem are you having with synchronising GIC accesses? > > As far as I can see, the CPU sending the IPI can simply poke the > relevant register in the distributor without requiring any > synchronisation. The CPU receiving the IPI is the only CPU with access > to its CPU interface. > > Could you describe your problem in more detail? > > Thanks, > Mark. > Hi Mark, Sorry for making confusions. I mean mutex between kernel and trustzone when accessing GIC registers. It is possible for they two issuing an accessing to the same register at the same time. How should I handle such kind of race conditions? >> On 12 January 2016 at 19:51, Mark Rutland wrote: >> > On Tue, Jan 12, 2016 at 09:38:20AM +, Lorenzo Pieralisi wrote: >> >> On Tue, Jan 12, 2016 at 10:17:42AM +0800, Zhaoyang Huang wrote: >> >> > On 12 January 2016 at 10:05, Zhaoyang Huang >> >> > wrote: >> >> > > In some ARM SOCs, IPI interrupt is used for hotplug in one cpu, that >> >> > > is, >> >> > > sending a IPI to the core in WFI and powerdown status. So Add a IPI >> >> > > entry for handle this kind of cpu up interrupt >> >> > > Launching the IPI can be done within PSCI, while there will be one >> >> > > unknown >> >> > > type of IPI as the dest core come up to the kernel world which will >> >> > > bring a >> >> > > warning so far.So add such type of IPI to handle the interrupt. >> >> >> >> You missed CC'ing ALKML for the second time and you were warned. >> >> >> >> You are adding a call to *send* an IPI in the kernel so the commit >> >> above is misleading. >> >> >> >> Acknowledge and clear the IRQ in FW so that the mechanism is completely >> >> implemented in FW (ie PSCI), that the CPU coming out of reset will run >> >> before getting to the kernel, this patch is not needed and we already >> >> explained to you why. >> >> >> >> Lorenzo >> > >> > I would also suggest that FW used the set of SGIs reserved for secure >> > usage (i.e. ID8 - ID15), as these will not conflict with those the >> > kernel uses. >> > >> > Thanks, >> > Mark. >>
RE: [PATCH v3 2/4] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
> -Original Message- > From: rkrc...@redhat.com [mailto:rkrc...@redhat.com] > Sent: Friday, January 22, 2016 1:21 AM > To: Wu, Feng > Cc: Yang Zhang ; pbonz...@redhat.com; linux- > ker...@vger.kernel.org; k...@vger.kernel.org > Subject: Re: [PATCH v3 2/4] KVM: x86: Use vector-hashing to deliver lowest- > priority interrupts > > Oh, I didn't notice 'ret' is initialized to true, I thought it was > > initialized > > to false like another function, I should add a "ret = false' here. We should > > failed to inject the interrupt since hardware disabled LAPIC is found. > > 'ret = true' is the better one. We know that the interrupt is not > deliverable [1], so there's no point in trying to deliver with the slow > path. We behave similarly when the interrupt targets a single disabled > APIC. Oh, yes, you are right, Thanks a lot! Thanks, Feng > > --- > 1: Well ... it's possible that slowpath would deliver it thanks to >different handling of disabled APICs, but it's undefined behavior, >so it doesn't matter matter if we don't try.
[PATCH v13 09/17] phy: Add driver for rockchip Display Port PHY
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
---
Changes in v13: None
Changes in v12:
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
function, move those code to probe() method. And remove driver .owner
number. (Kishon)
Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
power control. (Heiko)
Changes in v2: None
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 151 ++
3 files changed, 159 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 03cb3ea..cdb1c39 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -320,6 +320,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..88f09ec
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_SOC_CON12 0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+ int ret;
+
+ if (enable) {
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_ON);
+ if (ret < 0) {
+ dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dp->phy_24m);
+ } else {
+ clk_disable_unprepare(dp->phy_24m);
+
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_OFF);
+ }
+
+ return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct
[PATCH v13 11/17] drm: bridge: analogix/dp: add some rk3288 special registers setting
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 3858df5..1e24b37 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
#include
#include
+#include
+
#include "analogix_dp_core.h"
#include "analogix_dp_reg.h"
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+ writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+ writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+ writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+ }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
bool enable)
{
u32 reg;
+ u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+ if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+ writel(reg, dp->reg_base + phy_pd_addr);
} else {
- reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+ reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
- writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+
Re: [PATCH v3 5/5] firmware: add an extensible system data helpers
On Mon, Jan 04, 2016 at 12:31:58PM -0800, Kees Cook wrote: > On Wed, Dec 23, 2015 at 1:34 PM, Luis R. Rodriguez > wrote: > > In order to try to help phase out user mode helpers this makes no use of > > the old user mode helper code *at all*, and if we wish to can easily > > phase this code out with time then. > > So these are basically wrappers around the existing firmware loading routines? No, Greg has noted we cannot get rid of the usermode helper [0]. In fact at kernel summit he mentioned there are a series of upcoming valid users who seem to *want* it. Even Linus has called for deprecating the usermode helper [1] entirely if possible. This work tries to enable such prospects despite some needing the usermode helper by enabling callers that *need* the usermode helper to use the crappy usermode helper and letting us slowly dig that into a dark corner. This paves the path with a shiny extensible API with prospects of future features (fw signingin will be one) without use of the usermode helper at all, the extensible API enables new extensions by avoiding unnecessary collateral evolutions as this code / features get added. This provides a clean an way to enable folks who do wish to deprecate and the usermode helper to do so and provides carrots for doing that. [0] https://marc.info/?i=20151006090821.GB9030%40kroah.com [1] https://marc.info/?l=linux-kernel&m=144095832412928 Luis
[PATCH v13 13/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 4fa8aca..ade5d8e 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -56,6 +56,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+force-hpd (optional)
Deprecated properties for DisplayPort:
-interlaced:deprecated prop that can parsed from drm_display_mode.
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a62e8d0..13986b7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -62,15 +62,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "fa
[PATCH v13 14/17] drm: bridge: analogix/dp: move hpd detect to connector detect function
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 13986b7..cfdf695 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -904,12 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_detect_hpd(dp);
- if (ret) {
- /* Cable has been disconnected, we're done */
- return;
- }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -972,6 +966,11 @@ static const struct drm_connector_helper_funcs
analogix_dp_connector_helper_func
enum drm_connector_status
analogix_dp_detect(struct drm_connector *connector, bool force)
{
+ struct analogix_dp_device *dp = to_dp(connector);
+
+ if (analogix_dp_detect_hpd(dp))
+ return connector_status_disconnected;
+
return connector_status_connected;
}
@@ -1051,13 +1050,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge
*bridge)
pm_runtime_get_sync(dp->dev);
- if (dp->plat_data->panel) {
- if (drm_panel_prepare(dp->plat_data->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return;
- }
- }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
@@ -1090,11 +1082,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
- if (dp->plat_data->panel) {
- if (drm_panel_unprepare(dp->plat_data->panel))
- DRM_ERROR("failed to turnoff the panel\n");
- }
-
pm_runtime_put_sync(dp->dev);
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1352,6 +1339,15 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
pm_runtime_enable(dev);
+ phy_power_on(dp->phy);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1385,6 +1381,12 @@ void analogix_dp_unbind(struct device *dev, struct
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
analogix_dp_bridge_disable(dp->bridge);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
pm_runtime_disable(dev);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
--
1.9.1
[PATCH v13 16/17] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bc59e8d..5292b28 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1400,6 +1400,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);
clk_disable_unprepare(dp->clock);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1415,6 +1421,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_resume);
--
1.9.1
[PATCH v13 15/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
power on before driver try to read edid message.
Changes in v3:
- Add edid modes parse support
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 17
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
2 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index cfdf695..bc59e8d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -110,7 +110,7 @@ static unsigned char
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
static int analogix_dp_read_edid(struct analogix_dp_device *dp)
{
- unsigned char edid[EDID_BLOCK_LENGTH * 2];
+ unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -904,12 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_handle_edid(dp);
- if (ret) {
- dev_err(dp->dev, "unable to handle edid\n");
- return;
- }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
dp->video_info.max_link_rate);
if (ret) {
@@ -939,8 +933,14 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
int analogix_dp_get_modes(struct drm_connector *connector)
{
struct analogix_dp_device *dp = to_dp(connector);
+ struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
+ if (analogix_dp_handle_edid(dp) == 0) {
+ drm_mode_connector_update_edid_property(&dp->connector, edid);
+ num_modes += drm_add_edid_modes(&dp->connector, edid);
+ }
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
@@ -978,6 +978,7 @@ static void analogix_dp_connector_destroy(struct
drm_connector *connector)
{
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
+
}
static const struct drm_connector_funcs analogix_dp_connector_funcs = {
@@ -1348,6 +1349,8 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
}
}
+ analogix_dp_init_dp(dp);
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index a8cba64..40a0759 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
#define MAX_CR_LOOP5
#define MAX_EQ_LOOP5
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR 0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH 0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM 0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x) (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x) (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
+
enum link_lane_count_type {
LANE_COUNT1 = 1,
LANE_COUNT2 = 2,
@@ -155,6 +177,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
+ u
[PATCH v13 17/17] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
OUT <-- analogix_dp_bridge
OUT <-- DRM IOCTL
The dead lock flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
IN --> analogix_dp_hotplug
IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in
previous step 1)
** Dead Lock Now **
It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.
The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.
Signed-off-by: Yakir Yang
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 26 +
3 files changed, 55 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5292b28..7699597 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -851,47 +851,40 @@ static void analogix_dp_enable_scramble(struct
analogix_dp_device *dp,
}
}
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
{
struct analogix_dp_device *dp = arg;
-
+ irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;
irq_type = analogix_dp_get_irq_type(dp);
- switch (irq_type) {
- case DP_IRQ_TYPE_HP_CABLE_IN:
- dev_dbg(dp->dev, "Received irq - cable in\n");
- schedule_work(&dp->hotplug_work);
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CABLE_OUT:
- dev_dbg(dp->dev, "Received irq - cable out\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CHANGE:
- /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
- dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- default:
- dev_err(dp->dev, "Received irq - unknown type!\n");
- break;
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_mute_hpd_interrupt(dp);
+ ret = IRQ_WAKE_THREAD;
}
- return IRQ_HANDLED;
+
+ return ret;
}
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
{
- struct analogix_dp_device *dp;
+ struct analogix_dp_device *dp = arg;
+ enum dp_irq_type irq_type;
+
+ irq_type = analogix_dp_get_irq_type(dp);
+ if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+ irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+ dev_dbg(dp->dev, "Detected cable status changed!\n");
+ if (dp->drm_dev)
+ drm_helper_hpd_irq_event(dp->drm_dev);
+ }
- dp = container_of(work, struct analogix_dp_device, hotplug_work);
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_clear_hotplug_interrupts(dp);
+ analogix_dp_unmute_hpd_interrupt(dp);
+ }
- if (dp->drm_dev)
- drm_helper_hpd_irq_event(dp->drm_dev);
+ return IRQ_HANDLED;
}
static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1077,7 +1070,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
}
disable_irq(dp->irq);
- flush_work(&dp->hotplug_work);
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
@@ -1336,8 +1328,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
return -ENODEV;
}
- INIT_WORK(&dp->hotplug_work, analogix_dp_hotplug);
-
pm_runtime_enable(dev)
[PATCH v13 06/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)
Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
7 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
&dp {
status = "okay";
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
&dp {
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408..ee94110 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
- samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
};
&ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f0..8baf40a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 1cc2e95..fc232b
[PATCH v13 07/17] drm: rockchip: dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Heiko Stuebner
---
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
and leave "sclk_edp" to analogix dp core driver which name to "dp",
and leave "pclk_edp" to rockchip dp platform driver which name to
"pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384
include/drm/bridge/analogix_dp.h| 1 +
4 files changed, 395 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..9fe4e32 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,12 @@ config ROCKCHIP_DW_MIPI_DSI
for the Synopsys DesignWare HDMI driver. If you want to
enable MIPI DSI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_ANALOGIX_DP
+ tristate "Rockchip specific extensions for Analogix DP driver"
+ depends on DRM_ROCKCHIP
+ select DRM_ANALOGIX_DP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index d1dc0f7..40d4c94 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..b7af1b7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,384 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan
+ * Yakir Yang
+ * Jeff Chen
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+ struct drm_device*drm_dev;
+ struct device*dev;
+ struct drm_encoder encoder;
+ struct drm_display_mode mode;
+
+ struct clk *pclk;
+ struct regmap*grf;
+ struct reset_co
[PATCH v13 12/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
flag. (Thierry)
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 4 +--
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 26359f4..a62e8d0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1203,16 +1203,25 @@ static int analogix_dp_dt_parse_pdata(struct
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = &dp->video_info;
- if (of_property_read_u32(dp_node, "samsung,link-rate",
-&video_info->link_rate)) {
- dev_err(dp->dev, "failed to get link-rate\n");
- return -EINVAL;
- }
-
- if (of_property_read_u32(dp_node, "samsung,lane-count",
-&video_info->lane_count)) {
- dev_err(dp->dev, "failed to get lane-count\n");
- return -EINVAL;
+ switch (dp->plat_data->dev_type) {
+ case RK3288_DP:
+ /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+ video_info->max_link_rate = 0x0A;
+ video_info->max_lane_count = 0x04;
+ break;
+ case EXYNOS_DP:
+ /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+ of_property_read_u32(dp_node, "samsung,link-rate",
+&video_info->max_link_rate);
+ of_property_read_u32(dp_node, "samsung,lane-count",
+&video_info->max_lane_count);
+ break;
}
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d488dd6..6cc53d4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -123,8 +123,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- int link_rate;
- enum link_lane_count_type lane_count;
+ int max_link_rate;
+ enum link_lane_count_type max_lane_count;
};
struct link_train {
--
1.9.1
[PATCH v13 10/17] dt-bindings: add document for rockchip dp phy
Add dt binding documentation for rockchip display port PHY.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v13: None
Changes in v12: None
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Simplify the commit message. (Kishon)
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
elemets in document. (Rob & Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+- clock-names: from common clock binding:
+ Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ rockchip,grf = <&grf>;
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+};
--
1.9.1
[PATCH v13 08/17] dt-bindings: add document for rockchip variant of analogix_dp
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Modify the commit subject name. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../display/rockchip/analogix_dp-rockchip.txt | 91 ++
1 file changed, 91 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..04d99e3
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+ Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the output of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+ dp-controller: dp@ff97 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff97 0x4000>;
+ interrupts = ;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ rockchip,grf = <&grf>;
+ resets = <&cru 111>;
+ reset-names = "dp";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hpd>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ edp_out_panel: endpoint {
+ reg = <0>;
+ remote-endpoint = <&panel_in_edp>
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ edp {
+ edp_hpd: edp-hpd {
+ rockchip,pins = <7 11 RK_FUNC_2
&pcfg_pull_none>;
+ };
+ };
+ };
--
1.9.1
[PATCH v13 05/17] dt-bindings: add document for analogix display port driver
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50
.../bindings/display/exynos/exynos_dp.txt | 92 ++
2 files changed, 76 insertions(+), 66 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index fe4a7a2..4fa8aca 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -1,20 +1,3 @@
-Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
-
-DisplayPort is industry standard to accommodate the growing board adoption
-of digital display technology within the PC and CE industries.
-It consolidates the internal and external connection methods to reduce device
-complexity and cost. It also supports necessary features for important cross
-industry applications and provides performance scalability to enable the next
-generation of displays that feature higher color depths, refresh rates, and
-display resolutions.
-
-eDP (embedded display port) device is compliant with Embedded DisplayPort
-standard as follows,
-- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
-- DisplayPort standard 1.3 for Exynos5422s and Exynos5800.
-
-eDP resides b
[PATCH v13 04/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)
Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
struct drm_display_info. (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
3 files changed, 103 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b948636..26359f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1077,6 +1077,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ struct drm_display_info *display_info = &dp->connector.display_info;
+ struct video_info *video = &dp->video_info;
+ struct device_node *dp_node = dp->dev->of_node;
+ int vic;
+
+ /* Input video interlaces & hsync pol & vsync pol */
+ video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+ video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+ video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+ /* Input video dynamic_range & colorimetry */
+ vic = drm_match_cea_mode(mode);
+ if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+ (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR601;
+ } else if (vic) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ } else {
+ video->dynamic_range = VESA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ }
+
+ /* Input vide bpc and color_formats */
+ switch (display_info->bpc) {
+ case 12:
+ video->color_depth = COLOR_12;
+ break;
+ case 10:
+ video->color_depth = COLOR_10;
+ break;
+ case 8:
+ video->color_depth = COLOR_8;
+ break;
+ case 6:
+ video->color_depth = COLOR_6;
+ break;
+ default:
+ video->color_depth = COLOR_8;
+ break;
+ }
+ if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ video->color_space = COLOR_YCBCR444;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ video->color_space = COLOR_YCBCR422;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+ video->color_space = COLOR_RGB;
+ else
+ video->color_space = COLOR_RGB;
+
+ /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property is
[PATCH v13 03/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12:
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h
(Jingoo)
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
directly, but we can take those as hardware limite. For example, RK3288
only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
like "link-rate = 0x0a" "lane-count = 4". (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 14 +++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 7 +--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6901a6f..b948636 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -627,6 +627,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
*bandwidth = data;
@@ -647,7 +649,7 @@ static void analogix_dp_get_max_rx_lane_count(struct
analogix_dp_device *dp,
static void analogix_dp_init_training(struct analogix_dp_device *dp,
enum link_lane_count_type max_lane,
- enum link_rate_type max_rate)
+ int max_rate)
{
/*
* MACRO_RST must be applied after the PLL_LOCK to avoid
@@ -659,11 +661,12 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_bandwidth(dp, &dp->link_train.link_rate);
analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
- if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
- (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+ if ((dp->link_train.link_rate != DP_LINK_BW_1_62) &&
+ (dp->link_train.link_rate != DP_LINK_BW_2_7) &&
+ (dp->link_train.link_rate != DP_LINK_BW_5_4)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
- dp->link_train.link_rate = LINK_RATE_1_62GBPS;
+ dp->link_train.link_rate = DP_LINK_BW_1_62;
}
if (dp->link_train.lane_count == 0) {
@@ -901,9 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
- analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
- analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f7dfc8e..911642e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,11 +20,6 @@
#define MAX_CR_LOOP5
#define MAX_EQ_LOOP5
-enum link_rate_type {
- LINK_RATE_1_62GBPS = 0x06,
- LINK_RATE_2_70GBPS = 0x0a
-};
-
enum link_lane_count_type {
LANE_COUNT1 = 1,
LANE_COUNT2 = 2,
@@ -128,7 +123,7 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
- enum link_rate_type link_rate;
+ int link_rate;
enum link_lane_count_type lane_count;
};
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a388c0a..eb0b63c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -855,7 +855,7 @@ void analogix_dp_set_link_bandwidth(struct
analogix_dp_device *dp, u32 bwtype)
u32 reg;
reg = bwtype;
- if ((bwtype == LINK_RATE_2_70GBPS) || (bwtype == LINK_RATE_1_
[PATCH v13 02/17] drm: bridge: analogix/dp: fix some obvious code style
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Signed-off-by: Yakir Yang
Acked-by: Jingoo Han
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12:
- Add the ack from Jingoo
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
uncommon style like bellow: (Joe Preches)
- retval = exynos_dp_read_bytes_from_i2c(...
...);
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 72 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 124 ++--
3 files changed, 163 insertions(+), 162 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 392c296..6901a6f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -64,7 +64,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -101,8 +101,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- &extend_block);
+ EDID_EXTENSION_FLAG,
+ &extend_block);
if (retval)
return retval;
@@ -110,7 +110,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = analogix_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
+ retval = analogix_dp_read_bytes_from_i2c(dp,
+ I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
&edid[EDID_HEADER_PATTERN]);
@@ -141,7 +142,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
}
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- &test_vector);
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -155,10 +156,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- &edid[EDID_HEADER_PATTERN]);
+ I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -169,16 +168,13 @@ static int analogix_dp_read_edid(struct
analogix_dp_device *dp)
return -EIO;
}
- analogix_dp_read_byte_from_dpcd(dp,
- DP_TEST_REQUEST,
- &test_vector);
+ analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+ &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
[PATCH v13 0/17] Add Analogix Core Display Port Driver
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM
But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to
splict the connector init to platform driver anymore, and this is the biggest
change since version 11.
Previous version have been well tested on Rockchip platform and Samsung
platform,
but for this version Heiko and me have verified on Rockchip Veyron Chromebook.
Thanks,
- Yakir
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper(Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h
(Jingoo)
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9:
- Document more details for 'ports' property.
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify th
RE: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination
> -Original Message-
> From: Radim Krčmář [mailto:rkrc...@redhat.com]
> Sent: Friday, January 22, 2016 12:20 AM
> To: Wu, Feng
> Cc: pbonz...@redhat.com; linux-kernel@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the
> interrupt is not single-destination
>
> 2016-01-20 09:42+0800, Feng Wu:
> > When the interrupt is not single destination any more, we need
> > to change back IRTE to remapped mode explicitly.
> >
> > Signed-off-by: Feng Wu
> > ---
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > @@ -10764,8 +10764,17 @@ static int vmx_update_pi_irte(struct kvm
> *kvm, unsigned int host_irq,
> > - if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu))
> > + if (!kvm_intr_is_single_vcpu(kvm, &irq, &vcpu)) {
> > + /*
> > +* Make sure the IRTE is in remapped mode if
> > +* we don't handle it in posted mode.
> > +*/
> > + pi_set_sn(vcpu_to_pi_desc(vcpu));
>
> What could go wrong if we didn't suppress notifications here?
This is a good question. I also thought about this before, but after
thinking it a bit more, seems we don't need to do this.
If we don't do this, the in-flight interrupts will continue to be
delivered in PI mode while we are changing it to remapped
mode in IRTE. Even if we do this, the in-flight interrupts are
also delivered in PI mode before setting 'SN' anyway, so seems
we really don't need this, what is your opinion?
Thanks,
Feng
Thanks,
Feng
>
> Thanks.
>
> > + ret = irq_set_vcpu_affinity(host_irq, NULL);
> > + pi_clear_sn(vcpu_to_pi_desc(vcpu));
> > +
> > continue;
> > + }
Re: [PATCH v2 04/10] rtc: max77686: Use a driver data struct instead hard-coded values
Hello Krzysztof,
On 01/21/2016 10:00 PM, Krzysztof Kozlowski wrote:
On 22.01.2016 05:23, Javier Martinez Canillas wrote:
The driver has some hard-coded values such as the minimum delay needed
before a RTC update or the mask used for the sec/min/hour/etc registers.
Use a data structure that contains these values and pass as driver data
using the platform device ID table for each device.
This allows to make the driver's ops callbacks more generic so other RTC
that are similar but don't have the same values can also be supported.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Add a max77686 prefix to rtc_driver_data. Suggested by Krzysztof Kozlowski.
- Comment about the .delay and .mask fields. Suggested by Krzysztof Kozlowski.
- Change .mask type to u8. Suggested by Krzysztof Kozlowski.
- Make .drv_data field const. Suggested by Krzysztof Kozlowski.
- Don't cast to drop const on .drv_data asign. Suggested by Krzysztof Kozlowski.
- Use platform_get_device_id() macro. Suggested by Krzysztof Kozlowski.
drivers/rtc/rtc-max77686.c | 51 ++
1 file changed, 34 insertions(+), 17 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 71ef2240b3fc..16033a2c2756 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -41,8 +41,6 @@
#define ALARM_ENABLE_SHIFT7
#define ALARM_ENABLE_MASK (1 << ALARM_ENABLE_SHIFT)
-#define MAX77686_RTC_UPDATE_DELAY 16000
-
enum {
RTC_SEC = 0,
RTC_MIN,
@@ -54,6 +52,13 @@ enum {
RTC_NR_TIME
};
+struct max77686_rtc_driver_data {
+ /* Minimum delay needed for a RTC update */
+ unsigned long delay;
+ /* Mask used to read RTC registers value */
+ u8 mask;
+};
+
struct max77686_rtc_info {
struct device *dev;
struct max77686_dev *max77686;
@@ -63,6 +68,8 @@ struct max77686_rtc_info {
struct regmap *regmap;
+ const struct max77686_rtc_driver_data *drv_data;
+
int virq;
int rtc_24hr_mode;
};
@@ -72,12 +79,19 @@ enum MAX77686_RTC_OP {
MAX77686_RTC_READ,
};
+static const struct max77686_rtc_driver_data max77686_drv_data = {
+ .delay = 1600,
16000.
wakealarm does not work with 1600.
Sigh, sorry for the silly typo error...
+ .mask = 0x7f,
+};
+
static void max77686_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
- int rtc_24hr_mode)
+ struct max77686_rtc_info *info)
{
- tm->tm_sec = data[RTC_SEC] & 0x7f;
- tm->tm_min = data[RTC_MIN] & 0x7f;
- if (rtc_24hr_mode)
+ int mask = info->drv_data->mask;
u8 mask
Right, I forgot to change this when used u8 for the mask field.
Best regards,
Krzysztof
If you don't mind I'll wait a couple of days before posting a v3
otherwise I may be re-spining too fast and spamming other people
that didn't have time to look at the series yet.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Re: [PATCH v3 3/5] firmware: fold successful fw read early
On Mon, Jan 04, 2016 at 03:48:29PM -0500, Josh Boyer wrote:
> On Wed, Dec 23, 2015 at 4:34 PM, Luis R. Rodriguez
> wrote:
> > From: David Howells
> >
> > We'll be folding in some more checks on fw_read_file_contents(),
> > this will make the success case easier to follow.
> >
> > Signed-off-by: David Howells
> > Signed-off-by: Luis R. Rodriguez
>
> Reviewed-by: Josh Boyer
Thanks Josh.
Mimi, this is the other patch that I was referring to.
Luis
>
> > ---
> > drivers/base/firmware_class.c | 16 +++-
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index d8148aa89b01..e10a5349aa61 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -361,20 +361,18 @@ static int fw_get_filesystem_firmware(struct device
> > *device,
> > continue;
> > rc = fw_read_file_contents(file, buf);
> > fput(file);
> > - if (rc)
> > + if (rc == 0) {
> > + dev_dbg(device, "system data: direct-loading
> > firmware %s\n",
> > + buf->fw_id);
> > + fw_finish_direct_load(device, buf);
> > + goto out;
> > + } else
> > dev_warn(device, "system data, attempted to load
> > %s, but failed with error %d\n",
> > path, rc);
> > - else
> > - break;
> > }
> > +out:
> > __putname(path);
> >
> > - if (!rc) {
> > - dev_dbg(device, "system data: direct-loading firmware %s\n",
> > - buf->fw_id);
> > - fw_finish_direct_load(device, buf);
> > - }
> > -
> > return rc;
> > }
> >
> > --
> > 2.6.2
> >
>
--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg
Re: [PATCH v3 4/5] firmware: generalize reading file contents as a helper
Greg,
Due to Mimi's awesome work on generalizing a common VFS file read [0] as
described as possible in the commit log below this patch will be dropped in
preference for Mimi's VFS work to go in first.
Mimi,
since your generic VFS routine is pretty much identical to fw_read_file()
defined here you could make use of hunks #2 and #3 below. To make this more
legible it does depend on another patch which simplifies things. You can feel
free to pick that up as part of your series if you see it helps. If it doesn't
help that's fine too, I'll just submit later, but since you're digging in the
same way as I was I figured this could help.
I'll copy on you the other patch next.
[0]
http//lkml.kernel.org/r/1453129886-20192-1-git-send-email-zo...@linux.vnet.ibm.com
Luis
On Wed, Dec 23, 2015 at 01:34:56PM -0800, Luis R. Rodriguez wrote:
> From: David Howells
>
> We'll want to reuse this same code later in order to read
> two separate types of file contents. This generalizes
> fw_read_file_contents() for reading a file and rebrands it
> as fw_read_file(). This new caller is now generic: the path
> used can be arbitrary and the caller is also agnostic to the
> firmware_class code now, this begs the possibility of code
> re-use with other similar callers in the kernel. For instance
> in the future we may want to share a solution with:
>
> - firmware_class: fw_read_file()
> - module: kernel_read()
> - kexec: copy_file_fd()
>
> While at it this also cleans up the exit paths on fw_read_file().
>
> Reviewed-by: Josh Boyer
> Signed-off-by: David Howells
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/base/firmware_class.c | 62
> +++
> 1 file changed, 39 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index e10a5349aa61..cd51a90ed012 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -291,34 +291,51 @@ static const char * const fw_path[] = {
> module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644);
> MODULE_PARM_DESC(path, "customized firmware image search path with a higher
> priority than default path");
>
> -static int fw_read_file_contents(struct file *file, struct firmware_buf
> *fw_buf)
> +/*
> + * Read the contents of a file.
> + */
> +static int fw_read_file(const char *path, void **_buf, size_t *_size)
> {
> - int size;
> + struct file *file;
> + size_t size;
> char *buf;
> int rc;
>
> + file = filp_open(path, O_RDONLY, 0);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + rc = -EINVAL;
> if (!S_ISREG(file_inode(file)->i_mode))
> - return -EINVAL;
> + goto err_file;
> size = i_size_read(file_inode(file));
> if (size <= 0)
> - return -EINVAL;
> + goto err_file;
> + rc = -ENOMEM;
> buf = vmalloc(size);
> if (!buf)
> - return -ENOMEM;
> + goto err_file;
> +
> rc = kernel_read(file, 0, buf, size);
> + if (rc < 0)
> + goto err_buf;
> if (rc != size) {
> - if (rc > 0)
> - rc = -EIO;
> - goto fail;
> + rc = -EIO;
> + goto err_buf;
> }
> +
> rc = security_kernel_fw_from_file(file, buf, size);
> if (rc)
> - goto fail;
> - fw_buf->data = buf;
> - fw_buf->size = size;
> + goto err_buf;
> +
> + *_buf = buf;
> + *_size = size;
> return 0;
> -fail:
> +
> +err_buf:
> vfree(buf);
> +err_file:
> + fput(file);
> return rc;
> }
>
> @@ -332,19 +349,21 @@ static void fw_finish_direct_load(struct device *device,
> }
>
> static int fw_get_filesystem_firmware(struct device *device,
> -struct firmware_buf *buf)
> + struct firmware_buf *buf)
> {
> int i, len;
> int rc = -ENOENT;
> - char *path;
> + char *path = NULL;
>
> path = __getname();
> if (!path)
> return -ENOMEM;
>
> + /*
> + * Try each possible firmware blob in turn till one doesn't produce
> + * ENOENT.
> + */
> for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
> - struct file *file;
> -
> /* skip the unset customized path */
> if (!fw_path[i][0])
> continue;
> @@ -356,23 +375,20 @@ static int fw_get_filesystem_firmware(struct device
> *device,
> break;
> }
>
> - file = filp_open(path, O_RDONLY, 0);
> - if (IS_ERR(file))
> - continue;
> - rc = fw_read_file_contents(file, buf);
> - fput(file);
> + rc = fw_read_file(path, &buf->data, &buf->size);
> if (rc == 0) {
> dev_dbg(device, "system data: direct-lo
Re: [PATCH v12.1 07/17] drm: rockchip: dp: add rockchip platform dp driver
Hi Heiko,
On 01/22/2016 03:11 AM, Heiko Stuebner wrote:
Hi Yakir,
Am Dienstag, 19. Januar 2016, 18:04:53 schrieb Yakir Yang:
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
[...]
+static int rockchip_dp_drm_create_encoder(struct rockchip_dp_device *dp)
+{
+ struct drm_encoder *encoder = &dp->encoder;
+ struct drm_device *drm_dev = dp->drm_dev;
+ struct device *dev = dp->dev;
+ int ret;
+
+ encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
+dev->of_node);
+ DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
+
+ ret = drm_encoder_init(drm_dev, encoder, &rockchip_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS);
should be
+ DRM_MODE_ENCODER_TMDS, NULL);
Ops, :-|
Exynos-side seems to be ok though.
With the adapted v12.1 patches it applies cleanly and display is working as
well. So with the thing above fixed, you could resubmit a full v13,
especially as you want to drop patch 16 as discussed there.
Got it :)
Thanks,
Yakir
Heiko
Re: [PATCH perf 3/4] perf tools: Fix unused variables: x86_{32,64}_regoffset_table
On 2016/1/21 23:41, Arnaldo Carvalho de Melo wrote: But... I think that the unflexible original code has a bug, one that makes it not work when using gcc6 :-\ So I think we should make it build in gcc6, using that patch (or does it have some other problem?) so that at least doing what we can do now can be done for those using gcc6. Then fix these shortcomings you detected. OK. His patch does what it claims to do. Please merge it first, then let's look into my problem. Thank you.
Re: [PATCH v3 5/5] firmware: add an extensible system data helpers
On Thu, Dec 24, 2015 at 06:26:39AM +0800, kbuild test robot wrote:
> reproduce: make htmldocs
> >> drivers/base/firmware_class.c:1336: warning: No description found for
> >> parameter 'sysdata'
> 1331/**
> 1332 * release_sysdata_file: - release the resource associated with
> the sysdata file
> 1333 * @sysdata_file: sysdata resource to release
> 1334 **/
> 1335void release_sysdata_file(const struct sysdata_file *sysdata)
> > 1336{
This was a kdoc warning, I've fixed it and this will be part of my
v5 respin.
Luis
Re: [PATCH] mmc: dw_mmc: remove struct block_settings
Hi, Shawn.
Applied this.
Thanks!
Best Regards,
Jaehoon Chung
On 01/21/2016 05:06 PM, Shawn Lin wrote:
> This patch remove struct block_settings since
> it never be used anywhere.
>
> Signed-off-by: Shawn Lin
> ---
>
> include/linux/mmc/dw_mmc.h | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
> index 89df7ab..e1f90b8 100644
> --- a/include/linux/mmc/dw_mmc.h
> +++ b/include/linux/mmc/dw_mmc.h
> @@ -242,14 +242,6 @@ struct dw_mci_dma_ops {
>
> struct dma_pdata;
>
> -struct block_settings {
> - unsigned short max_segs; /* see blk_queue_max_segments */
> - unsigned intmax_blk_size; /* maximum size of one mmc block */
> - unsigned intmax_blk_count; /* maximum number of blocks in one req*/
> - unsigned intmax_req_size; /* maximum number of bytes in one req*/
> - unsigned intmax_seg_size; /* see blk_queue_max_segment_size */
> -};
> -
> /* Board platform data */
> struct dw_mci_board {
> u32 num_slots;
>
Re: sched-freq locking
On Thursday, January 21, 2016 10:49:58 AM Juri Lelli wrote: > [+Punit, Javi] > > Hi Rafael, > > On 21/01/16 02:46, Rafael J. Wysocki wrote: > > On Wednesday, January 20, 2016 05:39:14 PM Steve Muckle wrote: > > > On 01/20/2016 05:22 PM, Rafael J. Wysocki wrote: > > > > One comment here (which may be a bit off in which case please ignore > > > > it). > > > > > > > > You seem to be thinking that sched-freq needs to be a cpufreq governor > > > > and thus be handled in the same way as ondemand, for example. > > > > > > That's true, I hadn't really given much thought to the alternative you > > > mention below. > > > > > > > > > > > However, this doesn't have to be the case in principle. For example, > > > > if we have a special driver callback specifically to work with > > > > sched-freq, > > > > it may just use that callback and bypass (almost) all of the usual > > > > cpufreq mechanics. This way you may avoid worrying about the governor > > > > locking and related ugliness entirely. > > > > > > That sounds good but I'm worried about other consequences of taking > > > cpufreq out of the loop. For example wouldn't we need a new way for > > > something like thermal to set frequency limits? > > > > I don't know from the top of my head, but that's at least worth > > investigating. > > > > Yes, that's an interesting alternative that we have to think through. > > > Maybe we can keep the interface for those things unchanged, but handle it > > differently under the hood? > > > > Let me see if I understand what you are proposing :). If we don't want > to duplicate too many things, maybe it is still feasible to just use > existing cpufreq mechanics to handle hotplug, sysfs, thermal, etc. (with > possibly minor modifications to be notified of events) and only create a > new method to ask the driver for frequency changes, since we will have > replicated policy and freq_table information inside sched-freq. Is that > what you were also thinking of by saying "bypass (almost) all the usual > cpufreq mechanics"? :) Yes, it is. Thanks, Rafael
[RFC PATCH] codingstyle: improve elisp for a better experience
This patch does use of more emacs functionalities which deliver to the
user indentation, commenting and white space highlighting.
As known tabs are the higher law and the prior elisp code enforces
that law for any lineup indentation.
However some trees have specific rules about line continuation
indentation. Even checkpatch.pl suggests the TABS+SPACES (lining up
under the open paren) for lineup the sequential lines.
This new elisp, in addition to allowing the automatic setup by tree,
can easily be modified for new configurations. Eg.
(when (or (string-match (concat source-path "/net") filename)
(string-match (concat source-path "/drivers/net") filename))
(setup-kernel-style 'extra-bottom-line t nil))
The above model can be used for a new tree just changing the tree path
and parameters of setup-kernel-style function.
setup-kernel-style function sets the kernel-comment-style,
kernel-lineup-tabs-only and kernel-lineup-maximum-tabs variables. They
are used by the functions kernel-comment-dwim and kernel-lineup-arglist.
The kernel-lineup-arglist function replaces the prior
c-lineup-arglist-tabs-only. Now it detects the maximum tabs allowed to
lineup and if it must use tabs and spaces instead of only tabs.
There are two cleanups for else and else if braces enabled when
auto-newline is on. These are comfortable and avoid wrong coding
style. For instance
void spam(int i)
{
if (i == 7) {
dosomething();
...
}
else
{
appears like this after the last open brace is typed:
void spam(int i)
{
if (i == 7) {
dosomething();
...
} else {
The same happens for else if opening braces.
This elisp adds the function kernel-align-to-equals. It makes the
aligning of variable initializations/assignments easier.
int x = 10;
char *str = "text";
x = 100;
After marked the region and pressed C-c a =
int x = 10;
char *str = "text";
x = 100;
Concerning to comments kernel-comment-dwim is an improved version of
comment-dwim. It comment/uncomment lines, regions or adds a new
indented comment after the code using the same key binding. Eg.
void f(int x, int y);
M-; in any position on the line
void f(int x, int y); /* */
M-; again
/* void f(int x, int y); */
M-; and again
void f(int x, int y);
For multi-line comments the result is
/*
* void f1(int x, int y);
* void f2(int x, int y);
*/
Emacs doesn't provide yet a 'net' comment style by default. This code
also does the magic when kernel-comment-style is set as 'extra-bottom-line.
/* void f1(int x, int y);
* void f2(int x, int y);
*/
Until now the comment-region doesn't tabify the comment, generating
spaces before the " * " comment-continue variable (this issue was
reported and patched in the to be released emacs-25) however this code
correctly tabify the commented result.
kernel-comment-dwim also removes trailing white spaces created by the
comment-region.
Finally the white space highlighting is a must to alert about long
lines, leading or trailing spaces and top or bottom empty lines.
Signed-off-by: Geyslan G. Bem
---
Notes:
I will gladly receive criticism about the code and the topic.
Documentation/CodingStyle | 192 --
1 file changed, 167 insertions(+), 25 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index c06f817..2030b98 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -500,41 +500,183 @@ uses are less than desirable (in fact, they are worse
than random
typing - an infinite number of monkeys typing into GNU emacs would never
make a good program).
-So, you can either get rid of GNU emacs, or change it to use saner
-values. To do the latter, you can stick the following in your .emacs file:
-
-(defun c-lineup-arglist-tabs-only (ignored)
- "Line up argument lists by tabs, not spaces"
- (let* ((anchor (c-langelem-pos c-syntactic-element))
+So, you can either get rid of GNU emacs, or change it to use saner values.
+To do the latter, you can stick the following in your emacs init file:
+
+(defconst kernel-column-limit 80
+ "It is only 80, get over it.")
+
+(defvar kernel-source-path "~/src/linux-trees"
+ "The kernel source path.")
+
+(defvar kernel-comment-style 'extra-lines
+ "Default style is 'extra-lines.
+The another option is 'extra-bottom-line")
+(make-variable-buffer-local 'kernel-comment-style)
+
+(defvar kernel-lineup-tabs-only nil
+ "If it is non-nil the kernel lineup indentation will make use of tabs only.
+When nil lineup indentation will use TABS + SPACES.")
+(make-variable-buffer-local 'kernel-lineup-tabs-only)
+
+(defvar kernel-lineup-maximum-tabs nil
+ "If it is non-nil its value will be the maximum tabs steps in kernel lineup
+indentation.
+When nil there will not be such a limit.
+In both c
Re: [PATCH] cpuidle: fix fallback mechanism for suspend to idle in absence of enter_freeze
On Thursday, January 21, 2016 11:19:29 AM Sudeep Holla wrote:
> Commit 51164251f5c3 ("sched / idle: Drop default_idle_call() fallback
> from call_cpuidle()") made find_deepest_state() return non-negative
> value and check all the states with index > 0. Also a result,
> find_deepest_state() returns 0 even when enter_freeze callbacks are not
> implemented and enter_freeze_proper is called which ends up crashing
> the kernel.
>
> This patch updates the check for index > 0 in cpuidle_enter_freeze and
> cpuidle_idle_call(when idle_should_freeze is true) to restore the
> suspend-to-idle functionality in absence of enter_freeze callback.
>
> Fixes: 51164251f5c3 ("sched / idle: Drop default_idle_call() fallback from
> call_cpuidle()")
> Cc: "Rafael J. Wysocki"
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Signed-off-by: Sudeep Holla
> ---
> drivers/cpuidle/cpuidle.c | 2 +-
> kernel/sched/idle.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Hi Rafael,
Hi,
Sorry for the breakage.
> I assume you prefer to retain find_deepest_state return non-negative
> values, so I took this approach for fixing the bug. Do you think we
> need to support enter_freeze_proper for index 0 ?
Zero is a special case on x86, so supporting enter_freeze_proper() for it
is not necessary.
If you think we can also make 0 a special case on ARM, the others should
not object to that either.
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 046423b0c5ca..f996efc56605 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -153,7 +153,7 @@ int cpuidle_enter_freeze(struct cpuidle_driver *drv,
> struct cpuidle_device *dev)
>* be frozen safely.
>*/
> index = find_deepest_state(drv, dev, UINT_MAX, 0, true);
> - if (index >= 0)
> + if (index > 0)
> enter_freeze_proper(drv, dev, index);
>
> return index;
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index de0e786b2667..544a7133cbd1 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -162,7 +162,7 @@ static void cpuidle_idle_call(void)
>*/
> if (idle_should_freeze()) {
> entered_state = cpuidle_enter_freeze(drv, dev);
> - if (entered_state >= 0) {
> + if (entered_state > 0) {
> local_irq_enable();
> goto exit_idle;
> }
> --
> 1.9.1
>
Thanks,
Rafael
Re: [BUG] Regression introduced with "block: split bios to max possible length"
On Thu, Jan 21, 2016 at 2:51 PM, Keith Busch wrote: > > My apologies for the trouble. I trust it really is broken, but I don't > quite see how. The patch supposedly splits the transfer to the max size > the request queue says it allows. How does the max allowed size end up > an invalid multiple? I assume that in this case it's simply that - max_sectors is some odd number in sectors (ie 65535) - the block size is larger than a sector (ie 4k) - the device probably doesn't even have any silly chunk size issue (so chunk_sectors is zero). and because the block size is 4k, no valid IO can ever generate anything but 4k-aligned IO's, and everything is fine. Except now the "split bios" patch will split blindly at the max_sectors size, which is pure and utter garbage, since it doesn't take the minimum block size into account. Also, quite frankly, I think that whole "split bios" patch is garbage *anyway*. The thing is, the whole "blk_max_size_offset()" use there is broken. What I think it _should_ do is: (a) check against max sectors like it used to do: if (sectors + (bv.bv_len >> 9) > queue_max_sectors(q)) goto split; (b) completely separately, and _independently_ of that max sector check, it should check against the "chunk_sectors" limit if it exists. instead, it uses that nasty blk_max_size_offset() crap, which is broken because it's confusing, but also because it doesn't honor max_sectors AT ALL if there is a chunking size. So I think chunking size should be independent of max_sectors. I could see some device that has some absolute max sector size, but that _also_ wants to split so that the bio never crosses a particular chunk size (perhaps due to RAID, perhaps due to some internal device block handling rules). Trying to mix the two things with those "blk_max_size_offset()" games is just wrong. Linus
[PATCH] watchdog: Add watchdog timer support for the WinSystems EBC-C384
The WinSystems EBC-C384 has an onboard watchdog timer. The timeout range
supported by the watchdog timer is 1 second to 255 minutes. Timeouts
under 256 seconds have a 1 second resolution, while the rest have a 1
minute resolution.
This driver adds watchdog timer support for this onboard watchdog timer.
The timeout may be configured via the timeout module parameter.
Signed-off-by: William Breathitt Gray
---
MAINTAINERS | 6 ++
drivers/watchdog/Kconfig| 9 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/ebc-c384_wdt.c | 226
4 files changed, 242 insertions(+)
create mode 100644 drivers/watchdog/ebc-c384_wdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b1e3da7..c058abf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11629,6 +11629,12 @@ M: David Härdeman
S: Maintained
F: drivers/media/rc/winbond-cir.c
+WINSYSTEMS EBC-C384 WATCHDOG DRIVER
+M: William Breathitt Gray
+L: linux-watch...@vger.kernel.org
+S: Maintained
+F: drivers/watchdog/ebc-c384_wdt.c
+
WIMAX STACK
M: Inaky Perez-Gonzalez
M: linux-wi...@intel.com
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4f0e7be..94569ec 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -711,6 +711,15 @@ config ALIM7101_WDT
Most people will say N.
+config EBC_C386_WDT
+ tristate "WinSystems EBC-C384 watchdog timer support"
+ depends on X86
+ select WATCHDOG_CORE
+ help
+ Enables watchdog timer support for the watchdog timer on the
+ WinSystems EBC-C384 motherboard. The timeout may be configured via
+ the timeout module parameter.
+
config F71808E_WDT
tristate "Fintek F71808E, F71862FG, F71869, F71882FG and F71889FG
Watchdog"
depends on X86
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f566753..1522316 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o
obj-$(CONFIG_ALIM1535_WDT) += alim1535_wdt.o
obj-$(CONFIG_ALIM7101_WDT) += alim7101_wdt.o
+obj-$(CONFIG_EBC_C386_WDT) += ebc-c384_wdt.o
obj-$(CONFIG_F71808E_WDT) += f71808e_wdt.o
obj-$(CONFIG_SP5100_TCO) += sp5100_tco.o
obj-$(CONFIG_GEODE_WDT) += geodewdt.o
diff --git a/drivers/watchdog/ebc-c384_wdt.c b/drivers/watchdog/ebc-c384_wdt.c
new file mode 100644
index 000..1d7bd67
--- /dev/null
+++ b/drivers/watchdog/ebc-c384_wdt.c
@@ -0,0 +1,226 @@
+/*
+ * Watchdog timer driver for the WinSystems EBC-C384
+ * Copyright (C) 2016 William Breathitt Gray
+ *
+ * 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
+
+#define MODULE_NAME "ebc-c384_wdt"
+#define WATCHDOG_TIMEOUT 60
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static unsigned timeout = WATCHDOG_TIMEOUT;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default="
+ __MODULE_STRING(WATCHDOG_TIMEOUT) ")");
+
+/**
+ * struct ebc_c384_wdt - Watchdog timer device private data structure
+ * @wdd: instance of struct watchdog_device
+ * @lock: synchronization lock to prevent race conditions
+ * @base: base port address of the device
+ * @extent:extent of port address region of the device
+ */
+struct ebc_c384_wdt {
+ struct watchdog_device wdd;
+ spinlock_t lock;
+ unsigned base;
+ unsigned extent;
+};
+
+static int ebc_c384_wdt_start(struct watchdog_device *wdev)
+{
+ struct ebc_c384_wdt *wdt = watchdog_get_drvdata(wdev);
+
+ return wdt->wdd.ops->set_timeout(wdev, wdt->wdd.timeout);
+}
+
+static int ebc_c384_wdt_stop(struct watchdog_device *wdev)
+{
+ struct ebc_c384_wdt *wdt = watchdog_get_drvdata(wdev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&wdt->lock, flags);
+
+ outb(0x00, wdt->base + 2);
+
+ spin_unlock_irqrestore(&wdt->lock, flags);
+
+ return 0;
+}
+
+static int ebc_c384_wdt_set_timeout(struct watchdog_device *wdev, unsigned t)
+{
+ struct ebc_c384_wdt *wdt = watchdog_get_drvdata(wdev);
+ unsigned long flags;
+ unsigned minutes = 0;
+
+ if (!t || t > wdt->wdd.max_timeout)
+ return -EINVAL;
+
+ spin_lock_irqsave(
Re: Crashes with 874bbfe600a6 in 3.18.25
On 01/21/2016 04:52 AM, Jan Kara wrote: > On Wed 20-01-16 13:39:01, Shaohua Li wrote: >> On Wed, Jan 20, 2016 at 10:19:26PM +0100, Jan Kara wrote: >>> Hello, >>> >>> a friend of mine started seeing crashes with 3.18.25 kernel - once >>> appropriate load is put on the machine it crashes within minutes. He >>> tracked down that reverting commit 874bbfe600a6 (this is the commit ID from >>> Linus' tree, in stable tree the commit ID is 1e7af294dd03) "workqueue: make >>> sure delayed work run in local cpu" makes the kernel stable again. I'm >>> attaching screenshot of the crash - sadly the initial part is missing but >>> it seems that we crashed when processing timers on otherwise idle CPU. This >>> is a production machine so experimentation is not easy but if we really >>> need more information it may be possible to reproduce the issue again and >>> gather it. >>> >>> Anyone has idea what is going on? I was looking into the code for a while >>> but so far I have no good explanation. It would be good to understand the >>> cause instead of just blindly reverting the commit from stable tree... >> >> Tejun fixed a bug in timer: 22b886dd10180939. is it included in 3.18.25? > > That doesn't seem to be included in 3.18-stable although it was CCed to > stable. > Sasha? Looks like it requires more than trivial backport (I think). Tejun? Thanks, Sasha
Re: [PATCH v2] drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION
On 2016年01月22日 02:19, John Keeping wrote:
If DRM_FBDEV_EMULATION is not selected in the config then we can save a
bit of space by not including the framebuffer code.
Signed-off-by: John Keeping
---
On Thu, 21 Jan 2016 17:52:51 +0100, Daniel Vetter wrote:
On Thu, Jan 21, 2016 at 01:53:46PM +, John Keeping wrote:
If DRM_FBDEV_EMULATION is not selected in the config then we should not
setup a framebuffer console.
It should just magically work, and this patch here just removes a bit more
dead code in the rockchip driver itself that's not needed in case fbdev
emulation is disabled.
Can you please double-check this is the case and then resend with a
clarified commit message?
You're right, it does work without this change, so this is just to save
a bit of space when we don't need this feature.
v2:
- change commit message to clarify that this is only to remove some dead
code
drivers/gpu/drm/rockchip/Makefile | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a4e03bc..f6a809a 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -2,8 +2,9 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
+rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchip_drm_gem.o rockchip_drm_vop.o
+rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
index 50432e9..73718c5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
@@ -15,7 +15,18 @@
#ifndef _ROCKCHIP_DRM_FBDEV_H
#define _ROCKCHIP_DRM_FBDEV_H
+#ifdef CONFIG_DRM_FBDEV_EMULATION
int rockchip_drm_fbdev_init(struct drm_device *dev);
void rockchip_drm_fbdev_fini(struct drm_device *dev);
+#else
+static inline int rockchip_drm_fbdev_init(struct drm_device *dev)
+{
+ return 0;
+}
+
+static inline void rockchip_drm_fbdev_fini(struct drm_device *dev)
+{
+}
+#endif
#endif /* _ROCKCHIP_DRM_FBDEV_H */
Looks good and it works on my popmetal board.
Applied to my branch:-) .
--
Ｍark Yao
Re: [PATCH v2 03/10] rtc: max77686: Use usleep_range() instead of msleep()
On 22.01.2016 05:23, Javier Martinez Canillas wrote: > Documentation/timers/timers-howto.txt suggest to use usleep_range() > instead of msleep() for small msec (1ms - 20ms) since msleep() will > often sleep for 20ms for any value in that range. > > This is fine in this case since 16ms is the _minimum_ delay required > by max77686 for an RTC update but by using usleep_range() instead of > msleep(), the driver can support other RTC IP blocks with a shorter > minimum delay (i.e: in the range of usecs instead of msecs). > > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Krzysztof Kozlowski > > --- > > Changes in v2: > - Add Krzysztof Kozlowski's Reviewed-by tag to patch #3. > - Fix typo error in changelog. Suggested by Krzysztof Kozlowski. > > drivers/rtc/rtc-max77686.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > Tested on Trats2 board with max77686: Tested-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 04/10] rtc: max77686: Use a driver data struct instead hard-coded values
On 22.01.2016 05:23, Javier Martinez Canillas wrote:
> The driver has some hard-coded values such as the minimum delay needed
> before a RTC update or the mask used for the sec/min/hour/etc registers.
>
> Use a data structure that contains these values and pass as driver data
> using the platform device ID table for each device.
>
> This allows to make the driver's ops callbacks more generic so other RTC
> that are similar but don't have the same values can also be supported.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> Changes in v2:
> - Add a max77686 prefix to rtc_driver_data. Suggested by Krzysztof Kozlowski.
> - Comment about the .delay and .mask fields. Suggested by Krzysztof Kozlowski.
> - Change .mask type to u8. Suggested by Krzysztof Kozlowski.
> - Make .drv_data field const. Suggested by Krzysztof Kozlowski.
> - Don't cast to drop const on .drv_data asign. Suggested by Krzysztof
> Kozlowski.
> - Use platform_get_device_id() macro. Suggested by Krzysztof Kozlowski.
>
> drivers/rtc/rtc-max77686.c | 51
> ++
> 1 file changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
> index 71ef2240b3fc..16033a2c2756 100644
> --- a/drivers/rtc/rtc-max77686.c
> +++ b/drivers/rtc/rtc-max77686.c
> @@ -41,8 +41,6 @@
> #define ALARM_ENABLE_SHIFT 7
> #define ALARM_ENABLE_MASK(1 << ALARM_ENABLE_SHIFT)
>
> -#define MAX77686_RTC_UPDATE_DELAY16000
> -
> enum {
> RTC_SEC = 0,
> RTC_MIN,
> @@ -54,6 +52,13 @@ enum {
> RTC_NR_TIME
> };
>
> +struct max77686_rtc_driver_data {
> + /* Minimum delay needed for a RTC update */
> + unsigned long delay;
> + /* Mask used to read RTC registers value */
> + u8 mask;
> +};
> +
> struct max77686_rtc_info {
> struct device *dev;
> struct max77686_dev *max77686;
> @@ -63,6 +68,8 @@ struct max77686_rtc_info {
>
> struct regmap *regmap;
>
> + const struct max77686_rtc_driver_data *drv_data;
> +
> int virq;
> int rtc_24hr_mode;
> };
> @@ -72,12 +79,19 @@ enum MAX77686_RTC_OP {
> MAX77686_RTC_READ,
> };
>
> +static const struct max77686_rtc_driver_data max77686_drv_data = {
> + .delay = 1600,
16000.
wakealarm does not work with 1600.
> + .mask = 0x7f,
> +};
> +
> static void max77686_rtc_data_to_tm(u8 *data, struct rtc_time *tm,
> -int rtc_24hr_mode)
> + struct max77686_rtc_info *info)
> {
> - tm->tm_sec = data[RTC_SEC] & 0x7f;
> - tm->tm_min = data[RTC_MIN] & 0x7f;
> - if (rtc_24hr_mode)
> + int mask = info->drv_data->mask;
u8 mask
Best regards,
Krzysztof
Re: [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer
On 01/21/2016 12:19 PM, Jon Medhurst (Tixy) wrote:
On Thu, 2016-01-21 at 09:39 -0800, Laura Abbott wrote:
On 01/21/2016 03:57 AM, Jon Medhurst (Tixy) wrote:
From: Liviu Dudau
ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.
Signed-off-by: Liviu Dudau
Signed-off-by: Jon Medhurst
---
drivers/staging/android/ion/ion.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e237e9f..df56021 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -251,8 +251,10 @@ static struct ion_buffer *ion_buffer_create(struct
ion_heap *heap,
* memory coming from the heaps is ready for dma, ie if it has a
* cached mapping that mapping has been invalidated
*/
- for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i)
+ for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
sg_dma_address(sg) = sg_phys(sg);
+ sg_dma_len(sg) = sg->length;
+ }
mutex_lock(&dev->buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(&dev->buffer_lock);
So Ion is really doing it wrong by setting the sg_dma_address manually as
the comment above notes. Ion has moved away from sg_dma_len though
(see 06e0dcaeb4fd72a010a1f5ad0c03abd8e0a58ef9). This isn't technically
a mapping as well. What's broken by not having sg_dma_len set?
I fear this could end up being embarrassing...
What's broken is that the out-of-tree kernel driver for ARM's Mali GPU
is getting passed a dma_buf corresponding to the ION buffer. It is then
calling dma_buf_map_attachment [1] on that and then parsing the
resultant scatter-gather list to get the physical pages so it can pass
them to the GPU hardware. In the process, it is using sg_dma_len() to
get the length, which is garbage for ION buffers if ion_buffer_create()
doesn't set it.
[1]
http://git.linaro.org/landing-teams/working/arm/kernel-release.git/blob/9660bff61ab296be02aad111d0bc2b9919493de5:/drivers/gpu/arm/midgard/mali_kbase_jd.c#l333
Now, I just tried making the Mali driver use sg->length rather than
sg_dma_len() and, unsurprisingly, that also fixes the problem. So, my
questions would be...
Is it acceptable for a driver getting a dma_buf to parse the
scatter-gather list for that by had?
If so, should it use ->length or sg_dma_len() to get the length of each
element?
If sg_dma_len() is correct or acceptable then it seems to me that the
ION code should set that length. Especially as the comment in the code
implies it's faking a call to map_sg and grepping the kernel tree for
real implementations of that functionality seems to show the dma_address
getting set.
As you can probably tell, I feel I may be on shaky ground. This is
because I don't fully understanding the code and suspecting both the ION
and GPU code is rather dodgy (and possibly the bits in between :-)
I blame the Ion code completely. I remember hitting a similar problem
with other out of tree drivers. The solution then was to have drivers
switch to using sg->length instead of sg_dma_len given the state of that
tree. For the Mali driver, if it is ever going to be backed by an IOMMU
you will need to use sg_dma_len so I think at least that part of your
code is correct.
Thinking about it some, I'm okay with the patch going in. I thought
there was some reason why the out of tree code from before didn't just
do this hack but I can't remember it. It may have been an out of tree
use case. This does go well with Ion's behavior of pretending to do
DMA mapping. More out of tree users can plead their case if it breaks.
Acked-by: Laura Abbott
Re: [PATCH v2 02/10] rtc: max77686: Use ARRAY_SIZE() instead of current array length
On 22.01.2016 05:23, Javier Martinez Canillas wrote: > It is better to use the ARRAY_SIZE() macro instead of the array length > to avoid bugs if the array is later changed and the length not updated. > > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Krzysztof Kozlowski > > --- Tested on Trats2 board with max77686: Tested-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [Resend PATCH V5 0/1] AMD NTB V5 changes
On Thu, Jan 21, 2016 at 07:53:10PM +0800, Xiangliang Yu wrote: > Resend V5 for more convenient pick up. > Main changes in V5 > Only change Signed-off-by to Reviewed-by. Included in the NTB git tree. Thanks, Jon > > Xiangliang Yu (1): > [Resend patch V5] NTB: Add support for AMD PCI-Express Non-Transparent > Bridge > > MAINTAINERS |6 + > drivers/ntb/hw/Kconfig |1 + > drivers/ntb/hw/Makefile |1 + > drivers/ntb/hw/amd/Kconfig |7 + > drivers/ntb/hw/amd/Makefile |1 + > drivers/ntb/hw/amd/ntb_hw_amd.c | 1143 > +++ > drivers/ntb/hw/amd/ntb_hw_amd.h | 217 > 7 files changed, 1376 insertions(+) > create mode 100644 drivers/ntb/hw/amd/Kconfig > create mode 100644 drivers/ntb/hw/amd/Makefile > create mode 100644 drivers/ntb/hw/amd/ntb_hw_amd.c > create mode 100644 drivers/ntb/hw/amd/ntb_hw_amd.h > > -- > 1.9.1 >
Re: wireless-drivers: random cleanup patches piling up
On Thu, 2016-01-21 at 16:58 +0200, Kalle Valo wrote: > Hi, > > I have quite a lot of random cleanup patches from new developers waiting > in my queue: > > https://patchwork.kernel.org/project/linux-wireless/list/?state=10&delegate=25621&order=date > > (Not all of them are cleanup patches, there are also few patches > deferred due to other reasons, but you get the idea.) > > These cleanup patches usually take quite a lot of my time and I'm > starting to doubt the benefit, compared to the time needed to dig > through them and figuring out what to apply. And this is of course time > away from other patches, so it's slowing down "real" development. > > I really don't know what to do. Part of me is saying that I just should > drop them unless it's reviewed by a more experienced developer but on > the other hand this is a good way get new developers onboard. > > What others think? Are these kind of patches useful? Some yes, mostly not really. While whitespace style patches have some small value, very few of the new contributors that use tools like "scripts/checkpatch.pl -f" on various kernel files actually continue on to submit actual defect fixing or optimization or code clarity patches. Whitespace patches, where git diff -w does not show any difference and objdiff on the objects for a few randconfigs are identical, maybe could be sifted into a separate category from other patches. Maybe the kbuild test robot could help identify the whitespace style patches that can be easily applied. Maybe the kernel-janitors list should be used and also maybe some maintainers that want these style patches could opt-in to getting these applied after some milestone like an -rc1. Fengguang?
Re: [PATCH v2 01/10] rtc: max77686: Fix max77686_rtc_read_alarm() return value
On 22.01.2016 05:23, Javier Martinez Canillas wrote: > The function is always returning zero even in case of failures since > the ret value was not propagated to the callers. Fix the error path. > > Reported-by: Krzysztof Kozlowski > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v2: None > > drivers/rtc/rtc-max77686.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c > index 7184a0eda793..6653c3d11b66 100644 > --- a/drivers/rtc/rtc-max77686.c > +++ b/drivers/rtc/rtc-max77686.c > @@ -235,7 +235,7 @@ static int max77686_rtc_read_alarm(struct device *dev, > struct rtc_wkalrm *alrm) > > out: > mutex_unlock(&info->lock); > - return 0; > + return ret; > } > > static int max77686_rtc_stop_alarm(struct max77686_rtc_info *info) Reviewed-by: Krzysztof Kozlowski Tested on Trats2 board with max77686: Tested-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [RFC v1 4/8] x86/init: add linker table support
On 01/21/16 16:25, Luis R. Rodriguez wrote: >> >> Basically, if the hardware is enumerable using standard PC mechanisms (PCI, >> ACPI) and doesn't need a special boot flow it should use type 0. > > I can extend the documentation as part of this to be clear. > > I will note though that this still leaves a gap on code which might > want to access the question "are we in a virt environment, and if so > on which one" in between really early boot and right before > init_hypervisor_platform(). Or rather, given subarch can be used by > Xen and lguest but not KVM it means KVM doesn't get to use it. It may > not need it, but its also rather trivial to set up on qemu, and I have > a patch for that if we wanted one for KVM. That would extend the > definition of subarch a bit more, but as it stands today its use was > rather limited. Heck, subharch_data is to this day unused. > KVM is not a subarch, and Xen HVM isn't either; the subarch was meant to be specifically to handle nonstandard boot entries; the CE4100 extension was itself kind of a hack. If you have a genuine need for a "hypervisor type" then that is a separate thing and should be treated separately from subarch. However, you need to consider that some hypervisors can emulate other hypervisors and you may have more than one hypervisor API available. -hpa
Re: [PATCH] sched: loadavg 0.00, 0.01, 0.05 on idle
On 21/01/2016 19:38, Doug Smythies wrote: new = (old * 2037 + load * (2048 - 2037)) / 2048 new = (1862 * 2037 + 2048 * (2048 - 2037)) / 2048 new = 1862 So, the 100% load will always be shown as 91% (double the old limit). Math seems sound, but the fact is that the load on all my test machines now drops to 0.00/0.00/0.00 on idle, and increases to e.g. on my octa- core 8.00/8.00/8.00 on full load. I used mprime -t to cause a full load on all cores. load can never drop below 0, but can and will exceed 2048 unless nothing else is running, which is then likely the reason why 8.00 is actually reached for the 5 and 15 minute value despite the math here above. I would not worry too much about the accuracy, because, with or without the rounding, it takes more than three quarters of an hour to reach 100% 15-minute loadavg from idle, or the other way around 0% from full load. I have been running this proposed code with 100% load on CPU 7 for a couple of hours now, and the 15 minute load average is stuck at 0.91. In theory possible, but any instantaneous load above 100% will raise that 0.91 further. I think I can easily change the calc_load algorithm further to have the best of both worlds, but it will still take 45 minutes to reach a 15-minute avgload. After 40 minutes, and just to be sure, I checked again, and my buildhost now has the following load: 8.00, 8.02, 7.94. -- Vik
suspicious RCU usage in msr tracing.
Just hit this on Linus' current tree. [ INFO: suspicious RCU usage. ] 4.4.0-think+ #1 Tainted: GW --- ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! no locks held by swapper/3/0. stack backtrace: CPU: 3 PID: 0 Comm: swapper/3 Tainted: GW 4.4.0-think+ #1 8ef82ac0 c4dd1c3486ada576 880468e07f08 8e566ae1 880464905340 880468e07f38 8e135bf8 8f665b00 880464918000 88046492 880468e07f70 Call Trace: [] dump_stack+0x4e/0x7d [] lockdep_rcu_suspicious+0xf8/0x110 [] do_trace_write_msr+0x136/0x140 [] native_apic_msr_eoi_write+0x23/0x30 [] smp_call_function_single_interrupt+0x36/0x50 [] smp_call_function_interrupt+0xe/0x10 [] call_function_interrupt+0x90/0xa0 [] ? __asan_store4+0x80/0x80 [] ? poll_idle+0x67/0xc0 [] cpuidle_enter_state+0x174/0x430 [] cpuidle_enter+0x17/0x20 [] cpu_startup_entry+0x4c5/0x5a0 [] ? default_idle_call+0x60/0x60 [] ? clockevents_config_and_register+0x64/0x70 [] start_secondary+0x269/0x300 [] ? set_cpu_sibling_map+0x970/0x970 [ cut here ] 44 DEFINE_EVENT(msr_trace_class, write_msr, 45 TP_PROTO(unsigned msr, u64 val, int failed), 46 TP_ARGS(msr, val, failed) 47 ); Andi, could this be caused by 7f47d8cc039f8746e0038fe05f1ddcb15a2e27f0 ? Dave
Re: use-after-free in perf_trace_btrfs__work
Chris Mason wrote on 2016/01/21 12:06 -0500:
On Thu, Jan 14, 2016 at 10:07:31PM -0500, Dave Jones wrote:
I just hit a bunch of instances of this spew..
This is on Linus' tree from a few hours ago
==
BUG: KASAN: use-after-free in perf_trace_btrfs__work+0x1b1/0x2a0 [btrfs] at
addr 8800b7ea2e60
Read of size 8 by task trinity-c14/6745
=
BUG kmalloc-256 (Not tainted): kasan: bad access detected
-
Disabling lock debugging due to kernel taint
INFO: Allocated in btrfs_wq_submit_bio+0xd1/0x300 [btrfs] age=63 cpu=1 pid=6745
___slab_alloc.constprop.70+0x4de/0x580
__slab_alloc.isra.67.constprop.69+0x48/0x80
kmem_cache_alloc_trace+0x24c/0x2e0
btrfs_wq_submit_bio+0xd1/0x300 [btrfs]
btrfs_submit_bio_hook+0x118/0x260 [btrfs]
neigh_sysctl_register+0x201/0x360
devinet_sysctl_register+0x73/0xe0
inetdev_init+0x119/0x1f0
inetdev_event+0x5b3/0x7e0
notifier_call_chain+0x4e/0xd0
raw_notifier_call_chain+0x16/0x20
call_netdevice_notifiers_info+0x3d/0x70
register_netdevice+0x62d/0x730
register_netdev+0x1a/0x30
loopback_net_init+0x5d/0xd0
ops_init+0x5b/0x1e0
INFO: Freed in run_one_async_free+0x12/0x20 [btrfs] age=177 cpu=1 pid=8018
__slab_free+0x19e/0x2d0
kfree+0x24e/0x270
run_one_async_free+0x12/0x20 [btrfs]
btrfs_scrubparity_helper+0x38d/0x740 [btrfs]
btrfs_worker_helper+0xe/0x10 [btrfs]
process_one_work+0x417/0xa40
worker_thread+0x8b/0x730
kthread+0x199/0x1c0
ret_from_fork+0x3f/0x70
INFO: Slab 0xea0002dfa800 objects=28 used=28 fp=0x (null)
flags=0x40004080
INFO: Object 0x8800b7ea2da0 @offset=11680 fp=0x8800b7ea2480
static inline void __btrfs_queue_work(struct __btrfs_workqueue *wq,
struct btrfs_work *work)
{
unsigned long flags;
work->wq = wq;
thresh_queue_hook(wq);
if (work->ordered_func) {
spin_lock_irqsave(&wq->list_lock, flags);
list_add_tail(&work->ordered_list, &wq->ordered_list);
spin_unlock_irqrestore(&wq->list_lock, flags);
}
queue_work(wq->normal_wq, &work->normal_work);
trace_btrfs_work_queued(work);
}
Qu, 'work' can be freed before queue_work returns. I don't see any reason
here to have it after the queue_work() call, do you?
-chris
Right, trace_btrfs_work_queued() should be called at the very beginning.
I'll submit the fix soon.
Thanks,
Qu
Re: [PATCH 3/3] powercap, intel_rapl, Add ignore_max_time_window_check module parameter for broken BIOSes
On 2016-01-22 01:15, Prarit Bhargava wrote:
> Some systems erroneously set the maximum time window field of
> MSR_PKG_POWER_INFO register to 0. This results in a user not being able
> to set the time windows for the package. In some cases, however, RAPL
> will still continue to work with a small window (albeit through some
> trial and error). This patch adds a ignore_max_time_window_check module
> parameter to avoid the maximum time window check in set_time_window().
>
> [v2]: change name to max_time_window_check, fix (val == 0) check
>
> Cc: "Rafael J. Wysocki"
> Cc: Prarit Bhargava
> Cc: Radivoje Jovanovic
> Cc: Seiichi Ikarashi
> Cc: Mathias Krause
> Cc: Ajay Thomas
> Signed-off-by: Prarit Bhargava
> ---
> drivers/powercap/intel_rapl.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index 14753e5..939026d 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -505,13 +505,24 @@ static int get_max_time_window(struct powercap_zone
> *power_zone, int id,
>
> if (rapl_read_data_raw(rd, MAX_TIME_WINDOW, true, &val))
> ret = -EIO;
> - else
> + else {
> *data = val;
> -
> + if (val == 0)
> + pr_warn_once(FW_BUG "intel_rapl: Maximum Time Window is
> zero. This is a BIOS bug that should be reported to your hardware or BIOS
> vendor. The value of zero may prevent Intel RAPL from functioning properly.
> Most bugs can be avoided by setting the ignore_max_window_check module
> parameter.\n");
The correct name is
ignore_max_time_window_check here.
--
Seiichi
Re: [PATCH 1/3] powercap, intel_rapl, implement get_max_time_window
On 2016-01-22 01:15, Prarit Bhargava wrote: > The MSR_PKG_POWER_INFO register (Intel ASDM, section 14.9.3 > "Package RAPL Domain") provides a maximum time window which the > system can support. This window is read-only and is currently > not examined when setting the time windows for the package. > > This patch implements get_max_time_window_us() and checks the window when > a user attempts to set power capping for the package. > > Before the patch it was possible to set the window to, for example, 1 > micro seconds: > > [root@intel-chiefriver-03 rhel7]# echo 1 > > /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us; > egrep ^ > /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us > > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:1:9765 > > but from 'turbostat -d', the package is limited to 976us: > > cpu0: MSR_PKG_POWER_INFO: 0x01200168 (45 W TDP, RAPL 36 - 0 W, 0.000977 sec.) > > (Note, there appears to be a rounding issue in turbostat which needs to > also be fixed. Looking at the values in the register it is clear the > value is 1/1024 = 976us.) > > After the patch we are limited by the maximum time window: > > [root@intel-chiefriver-03 rhel7]# echo 1 > > /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us; > egrep ^ > /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_0_time_window_us > > -bash: echo: write error: Invalid argument > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_time_window_us:1:976 > > Cc: "Rafael J. Wysocki" > Cc: Prarit Bhargava > Cc: Radivoje Jovanovic > Cc: Seiichi Ikarashi > Cc: Mathias Krause > Cc: Ajay Thomas > Signed-off-by: Prarit Bhargava > --- > drivers/powercap/intel_rapl.c | 31 +++ > drivers/powercap/powercap_sys.c |6 -- > 2 files changed, 35 insertions(+), 2 deletions(-) > > diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c > index cc97f08..f765b2c 100644 > --- a/drivers/powercap/intel_rapl.c > +++ b/drivers/powercap/intel_rapl.c > @@ -493,13 +493,42 @@ static int get_current_power_limit(struct powercap_zone > *power_zone, int id, > return ret; > } > > +static int get_max_time_window(struct powercap_zone *power_zone, int id, > +u64 *data) The 2nd arg "id" is not necessary. -- Seiichi
Re: [PATCH 0/8] Support multi-order entries in the radix tree
On Tue, 19 Jan 2016 09:25:25 -0500 Matthew Wilcox wrote: > Before diving into the important modifications, I add Andrew Morton's > radix tree test harness to the tree in patches 1 & 2. It was absolutely > invaluable in catching some of my bugs. (cc Shuah for tools/testing/selftests) Cool, thanks for doing that. I think a lot of this came from Nick Piggin a long time ago, but I was bad about attributing it. I wonder how good the coverage is - I don't think it's been seriously updated since 2010 and presumably it isn't hitting on later-added features. Doesn't matter - someone will add things later if needed. And when I bug them to update the test harness ;) I don't think it will link on my system - I have no liburcu by default. I wonder if this will break lots of people's "make kselftest". I'll get all this into -next tomorrow. Hopefully Ross will have time to go through it sometime (non-urgently - it's 4.6 stuff).
Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables
On Thu, Jan 21, 2016 at 03:56:35PM -0800, H. Peter Anvin wrote: > On 01/21/16 14:25, Luis R. Rodriguez wrote: > > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk > > wrote: > >>> Sure, do we know if that ICC compatible? Do we care? There are a > >>> series of ICC hacks put in place on ipxe's original solution which > >>> I've folded in, it seems that works but if we care about ICC those > >>> folks should perhaps help review as well. > >> > >> I didn't know the kernel could even be compiled with ICC? Thought > >> only GCC worked? > > > > I'm happy with that, just wanted to make sure I raise the flag concern > > given the icc hacks on the linker tables. > > > >> Anyhow - it may be that those fixes were for quite old ICC versions. > >> Does the latest one manifest these oddities? > > > > I am not sure, I yield to Michael as the author of the original ICC > > compatibility pieces. If we don't care about ICC let me know and I'll > > just drop the stuff. In lack of such statements I'll just keep the > > work arounds in place, but I'm more than trilled to drop it. > > > > In general we let the ICC and Clang/LLVM teams communicate with out a > post facto. We can't just guess what their requirements are, especially > since they are likely to change between revisions. Great. I'm going to drop ICC hacks. Luis
Re: [RFC v1 4/8] x86/init: add linker table support
On Wed, Jan 20, 2016 at 2:20 PM, H. Peter Anvin wrote: > On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" > wrote: >>On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: >>> On 01/20/16 13:33, Luis R. Rodriguez wrote: That's correct for PV and PVH, likewise when qemu is required for >>HVM qemu could set it. I have the qemu change done but that should only cover HVM. A common place to set this as well could be the >>hypervisor, but currently the hypervisor doesn't set any boot_params, instead a generic struct is passed and the kernel code (for any OS) is >>expected to interpret this and then set the required values for the OS in the init path. Long term though if we wanted to merge init further one >>way could be to have the hypervisor just set the zero page cleanly for >>the different modes. If we needed more data other than the hardware_subarch we also have the hardware_subarch_data, that's a >>u64 , and how that is used would be up to the subarch. In Xen's case it could do what it wants with it. That would still mean perhaps >>defining as part of a Xen boot protocol a place where xen specific code can count on finding more Xen data passed by the hypervisor, the xen_start_info. That is, if we wanted to merge init paths this is something to consider. One thing I considered on the question of who should set the zero >>page for Xen with the prospect of merging inits, or at least this subarch for both short term and long term are the obvious implications in terms of hypervisor / kernel / qemu combination requirements if the subarch is needed. Having it set in the kernel is an obvious >>immediate choice for PV / PVH but it means we can't merge init paths >>completely (down to asm inits), we'd still be able to merge some C init paths though, the first entry would still be different. Having the zero >>page set on the hypervisor would go long ways but it would mean a hypervisor change required. These prospects are worth discussing, specially in light of Boris's hvmlite work. >>> >>> The above doesn't make sense to me. hardware_subarch is really used >>> when the boot sequence is somehow nonstandard. >> >>Thanks for the feedback -- as it stands today hardware_subarch is only >>used by lguest, Moorestown, and CE4100 even though we had definitions >>for it for Xen -- this is not used yet. Its documentation does make >>references to differences for a paravirtualized environment, and uses >>a few examples but doesn't go into great depths about restrictions so >>its limitations in how we could use it were not clear to me. >> >>> HVM probably doesn't need that. >> >>Today HVM doesn't need it, but perhaps that is because it has not >>needed changes early on boot. Will it, or could it? I'd even invite us >>to consider the same for other hypervisors or PV hypervisors. I'll >>note that things like cpu_has_hypervisor() or derivatives >>(kvm_para_available() which is now used on drivers even, see >>sound/pci/intel8x0.c) requires init_hypervisor_platform() run, in >>terms of the x86 init sequence this is run pretty late at >>setup_arch(). Should code need to know hypervisor info anytime before >>that they have no generic option available. >> >>I'm fine if we want to restrict hardware_subarch but I'll note the >>semantics were not that explicit to delineate clear differences and I >>just wanted to highlight the current early boot restriction of >>cpu_has_hypervisor(). >> >> Luis > > Basically, if the hardware is enumerable using standard PC mechanisms (PCI, > ACPI) and doesn't need a special boot flow it should use type 0. I can extend the documentation as part of this to be clear. I will note though that this still leaves a gap on code which might want to access the question "are we in a virt environment, and if so on which one" in between really early boot and right before init_hypervisor_platform(). Or rather, given subarch can be used by Xen and lguest but not KVM it means KVM doesn't get to use it. It may not need it, but its also rather trivial to set up on qemu, and I have a patch for that if we wanted one for KVM. That would extend the definition of subarch a bit more, but as it stands today its use was rather limited. Heck, subharch_data is to this day unused. Luis
Re: linux-next: build failure after merge of the akpm tree
Hi all,
On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell
wrote:
>
> On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai wrote:
> >
> > On Sat, 16 Jan 2016 09:51:29 +0100,
> > Takashi Iwai wrote:
> > >
> > > There are a few ways to fix this, but all are not comfortable.
> > >
> > > A. Disable compress API for powerpc.
>
> This also affects alpha, mips and (maybe) sparc.
This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
UBSAN support") which is in Linus' tree as of this morning. The only
relevant change that made was in the compiler flags (I tested this by
building the file without that commit but with these new compiler flags:
-fsanitize=shift -fsanitize=integer-divide-by-zero
-fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
-fsanitize=signed-integer-overflow -fsanitize=bounds
-fsanitize=object-size -fsanitize=returns-nonnull-attribute
-fsanitize=bool -fsanitize=enum -fsanitize=alignment
The preprocessed file is the same in both cases, but with these flags
the compiler errors.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
Re: [PATCH v4 07/21] usb: dwc2: hcd: fix split transfer schedule sequence
Hi,
On Wed, Jan 20, 2016 at 9:24 PM, kbuild test robot wrote:
> Hi Douglas,
>
> [auto build test ERROR on next-20160120]
> [cannot apply to v4.4-rc8 v4.4-rc7 v4.4-rc6 v4.4]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Douglas-Anderson/usb-dwc2-host-Fix-and-speed-up-all-the-stuff-especially-with-splits/20160121-131414
> config: x86_64-randconfig-x019-01201142 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>drivers/usb/dwc2/core.c: In function 'dwc2_hc_start_transfer':
>>> drivers/usb/dwc2/core.c:1876:17: error: 'struct dwc2_hsotg' has no member
>>> named 'split_order'
> &hsotg->split_order);
> ^
> --
>>> /bin/bash: line 0: [: -ge: unary operator expected
>
> vim +1876 drivers/usb/dwc2/core.c
>
> 1870 ec_mc = 3;
> 1871 else
> 1872 ec_mc = 1;
> 1873
> 1874 /* Put ourselves on the list to keep order straight */
> 1875 list_move_tail(&chan->split_order_list_entry,
>> 1876 &hsotg->split_order);
> 1877 } else {
> 1878 if (dbg_hc(chan))
> 1879 dev_vdbg(hsotg->dev, "no split\n");
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
I've got a fix this and the other error reported by the bot. I'll
plan to fix both tomorrow and send up a v5 unless someone gives me
some other feedback on the series that takes me longer than a day to
deal with.
-Doug
Re: [RFC v1 4/8] x86/init: add linker table support
On Thu, Jan 21, 2016 at 11:52 AM, H. Peter Anvin wrote:
> On 01/21/16 11:50, H. Peter Anvin wrote:
>>
>> Right... we already do that.
>>
>> I don't even think you need to initialize any tables. At least on i386,
>> we have to do this in assembly code. However, it is just a simple table
>> walk. :)
>>
>
> It might make more sense to make subarch its own table, though, although
> I haven't looked at your code in enough detail to say.
The gist of it:
void x86_init_fn_early_init() {
for_each_table_entry(init_fn, X86_INIT_FNS) {
if supported subarc
init_fn->early_init();
}
void x86_init_fn_setup_arch() {
for_each_table_entry(init_fn, X86_INIT_FNS) {
if supported subarc
init_fn->setup_archt();
}
Right now the code defines just an init routine at the stage for
x86_64_start_reservations(), we call the callback early_init(), ie
setup_arch() doesn't exist yet. Since certain routines can run on
either Xen or bare-metal we allow a bitwise OR for the subarch as a
bitmask. I'll think a bit more about how to use subarch for a table,
but can't fit it yet. I'd like to later revise kfree'ing unused
sections, and a table per subarch might be nice for that, but
otherwise this flow seems easy to follow, so if we can kfree sections
within a table we could still accomplish that later.
Luis
[PATCH 4/4] Add support for two new systems: ASM200 & ASM201
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index e66c34d..eccd547 100644
--- a/drivers/platform/x86/alienware-wmi.c
+++ b/drivers/platform/x86/alienware-wmi.c
@@ -97,6 +97,20 @@ static struct quirk_entry quirk_asm100 = {
.deepslp = 0,
};
+static struct quirk_entry quirk_asm200 = {
+ .num_zones = 2,
+ .hdmi_mux = 1,
+ .amplifier = 0,
+ .deepslp = 1,
+};
+
+static struct quirk_entry quirk_asm201 = {
+ .num_zones = 2,
+ .hdmi_mux = 1,
+ .amplifier = 1,
+ .deepslp = 1,
+};
+
static int __init dmi_matched(const struct dmi_system_id *dmi)
{
quirks = dmi->driver_data;
@@ -140,6 +154,24 @@ static const struct dmi_system_id alienware_quirks[]
__initconst = {
},
.driver_data = &quirk_asm100,
},
+ {
+.callback = dmi_matched,
+.ident = "Alienware ASM200",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
+DMI_MATCH(DMI_PRODUCT_NAME, "ASM200"),
+},
+.driver_data = &quirk_asm200,
+},
+ {
+.callback = dmi_matched,
+.ident = "Alienware ASM201",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
+DMI_MATCH(DMI_PRODUCT_NAME, "ASM201"),
+},
+.driver_data = &quirk_asm201,
+},
{}
};
--
1.9.1
[PATCH 3/4] Add support for deep sleep control.
This allows configuration the system for wakeup with a controller.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 103 ++-
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index e6f6322..e66c34d 100644
--- a/drivers/platform/x86/alienware-wmi.c
+++ b/drivers/platform/x86/alienware-wmi.c
@@ -1,7 +1,7 @@
/*
* Alienware AlienFX control
*
- * Copyright (C) 2014 Dell Inc
+ * Copyright (C) 2014-2016 Dell Inc
*
* 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
@@ -34,6 +34,8 @@
#define WMAX_METHOD_ZONE_CONTROL 0x4
#define WMAX_METHOD_HDMI_CABLE 0x5
#define WMAX_METHOD_AMPLIFIER_CABLE0x6
+#define WMAX_METHOD_DEEP_SLEEP_CONTROL 0x0B
+#define WMAX_METHOD_DEEP_SLEEP_STATUS 0x0C
MODULE_AUTHOR("Mario Limonciello ");
MODULE_DESCRIPTION("Alienware special feature control");
@@ -62,6 +64,7 @@ struct quirk_entry {
u8 num_zones;
u8 hdmi_mux;
u8 amplifier;
+ u8 deepslp;
};
static struct quirk_entry *quirks;
@@ -70,24 +73,28 @@ static struct quirk_entry quirk_unknown = {
.num_zones = 2,
.hdmi_mux = 0,
.amplifier = 0,
+ .deepslp = 0,
};
static struct quirk_entry quirk_x51_r1_r2 = {
.num_zones = 3,
.hdmi_mux = 0,
.amplifier = 0,
+ .deepslp = 0,
};
static struct quirk_entry quirk_x51_r3 = {
.num_zones = 4,
.hdmi_mux = 0,
.amplifier = 1,
+ .deepslp = 0,
};
static struct quirk_entry quirk_asm100 = {
.num_zones = 2,
.hdmi_mux = 1,
.amplifier = 0,
+ .deepslp = 0,
};
static int __init dmi_matched(const struct dmi_system_id *dmi)
@@ -650,6 +657,93 @@ error_create_amplifier:
return ret;
}
+/* Deep Sleep Control support
+ * - Modifies BIOS setting for deep sleep control allowing extra wakeup events
+*/
+static ssize_t show_deepsleep_status(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ acpi_status status;
+ u32 out_data;
+ struct wmax_basic_args in_args = {
+ .arg = 0,
+ };
+ status =
+ alienware_wmax_command(&in_args, WMAX_METHOD_DEEP_SLEEP_STATUS,
+ (u32 *) &out_data);
+ if (ACPI_SUCCESS(status)) {
+ if (out_data == 0)
+ return scnprintf(buf, PAGE_SIZE,
+"[disabled] s5 s5_s4\n");
+ else if (out_data == 1)
+ return scnprintf(buf, PAGE_SIZE,
+"disabled [s5] s5_s4\n");
+ else if (out_data == 2)
+ return scnprintf(buf, PAGE_SIZE,
+"disabled s5 [s5_s4]\n");
+ }
+ pr_err("alienware-wmi: unknown deep sleep status: %d\n", status);
+ return scnprintf(buf, PAGE_SIZE, "disabled s5 s5_s4 [unknown]\n");
+}
+
+static ssize_t toggle_deepsleep(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ acpi_status status;
+ struct wmax_basic_args args;
+
+ if (strcmp(buf, "disabled\n") == 0)
+ args.arg = 0;
+ else if (strcmp(buf, "s5\n") == 0)
+ args.arg = 1;
+ else
+ args.arg = 2;
+ pr_debug("alienware-wmi: setting deep sleep to %d : %s", args.arg, buf);
+
+ status =
+ alienware_wmax_command(&args, WMAX_METHOD_DEEP_SLEEP_CONTROL, NULL);
+
+ if (ACPI_FAILURE(status))
+ pr_err
+ ("alienware-wmi: deep sleep control failed: results: %u\n",
+status);
+ return count;
+}
+
+static DEVICE_ATTR(deepsleep, S_IRUGO | S_IWUSR, show_deepsleep_status,
+ toggle_deepsleep);
+
+static struct attribute *deepsleep_attrs[] = {
+ &dev_attr_deepsleep.attr,
+ NULL,
+};
+
+static struct attribute_group deepsleep_attribute_group = {
+ .name = "deepsleep",
+ .attrs = deepsleep_attrs,
+};
+
+static void remove_deepsleep(struct platform_device *dev)
+{
+ if (quirks->deepslp > 0)
+ sysfs_remove_group(&dev->dev.kobj, &deepsleep_attribute_group);
+}
+
+static int create_deepsleep(struct platform_device *dev)
+{
+ int ret;
+
+ ret = sysfs_create_group(&dev->dev.kobj, &deepsleep_attribute_group);
+ if (ret)
+ goto error_create_deepsleep;
+ return 0;
+
+error_create_deepsleep:
+ remove_deepsleep(dev);
+ return ret;
+}
+
static int __init alienware_wmi_init(void)
{
int ret;
@@ -691,6 +785,12 @@ static int __init alienware_wmi_init(void)
goto fail_pr
[PATCH 1/4] Add support for new platform, X51-R3
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 44
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index 1e1e594..dcd4f81 100644
--- a/drivers/platform/x86/alienware-wmi.c
+++ b/drivers/platform/x86/alienware-wmi.c
@@ -69,11 +69,16 @@ static struct quirk_entry quirk_unknown = {
.hdmi_mux = 0,
};
-static struct quirk_entry quirk_x51_family = {
+static struct quirk_entry quirk_x51_r1_r2 = {
.num_zones = 3,
.hdmi_mux = 0.
};
+static struct quirk_entry quirk_x51_r3 = {
+ .num_zones = 4,
+ .hdmi_mux = 0,
+};
+
static struct quirk_entry quirk_asm100 = {
.num_zones = 2,
.hdmi_mux = 1,
@@ -88,12 +93,12 @@ static int __init dmi_matched(const struct dmi_system_id
*dmi)
static const struct dmi_system_id alienware_quirks[] __initconst = {
{
.callback = dmi_matched,
-.ident = "Alienware X51 R1",
+.ident = "Alienware X51 R3",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
-DMI_MATCH(DMI_PRODUCT_NAME, "Alienware X51"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Alienware X51 R3"),
},
-.driver_data = &quirk_x51_family,
+.driver_data = &quirk_x51_r3,
},
{
.callback = dmi_matched,
@@ -102,17 +107,26 @@ static const struct dmi_system_id alienware_quirks[]
__initconst = {
DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
DMI_MATCH(DMI_PRODUCT_NAME, "Alienware X51 R2"),
},
-.driver_data = &quirk_x51_family,
+.driver_data = &quirk_x51_r1_r2,
+},
+ {
+.callback = dmi_matched,
+.ident = "Alienware X51 R1",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Alienware X51"),
+},
+.driver_data = &quirk_x51_r1_r2,
},
{
- .callback = dmi_matched,
- .ident = "Alienware ASM100",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
- DMI_MATCH(DMI_PRODUCT_NAME, "ASM100"),
- },
- .driver_data = &quirk_asm100,
- },
+.callback = dmi_matched,
+.ident = "Alienware ASM100",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Alienware"),
+DMI_MATCH(DMI_PRODUCT_NAME, "ASM100"),
+},
+.driver_data = &quirk_asm100,
+},
{}
};
@@ -477,7 +491,7 @@ static ssize_t show_hdmi_cable(struct device *dev,
};
status =
alienware_hdmi_command(&in_args, WMAX_METHOD_HDMI_CABLE,
- (u32 *) &out_data);
+ (u32 *) & out_data);
if (ACPI_SUCCESS(status)) {
if (out_data == 0)
return scnprintf(buf, PAGE_SIZE,
@@ -500,7 +514,7 @@ static ssize_t show_hdmi_source(struct device *dev,
};
status =
alienware_hdmi_command(&in_args, WMAX_METHOD_HDMI_STATUS,
- (u32 *) &out_data);
+ (u32 *) & out_data);
if (ACPI_SUCCESS(status)) {
if (out_data == 1)
--
1.9.1
[PATCH 2/4] Add support for alienware graphics amplifier
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 114 ---
1 file changed, 93 insertions(+), 21 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index dcd4f81..e6f6322 100644
--- a/drivers/platform/x86/alienware-wmi.c
+++ b/drivers/platform/x86/alienware-wmi.c
@@ -33,6 +33,7 @@
#define WMAX_METHOD_BRIGHTNESS 0x3
#define WMAX_METHOD_ZONE_CONTROL 0x4
#define WMAX_METHOD_HDMI_CABLE 0x5
+#define WMAX_METHOD_AMPLIFIER_CABLE0x6
MODULE_AUTHOR("Mario Limonciello ");
MODULE_DESCRIPTION("Alienware special feature control");
@@ -60,6 +61,7 @@ enum WMAX_CONTROL_STATES {
struct quirk_entry {
u8 num_zones;
u8 hdmi_mux;
+ u8 amplifier;
};
static struct quirk_entry *quirks;
@@ -67,21 +69,25 @@ static struct quirk_entry *quirks;
static struct quirk_entry quirk_unknown = {
.num_zones = 2,
.hdmi_mux = 0,
+ .amplifier = 0,
};
static struct quirk_entry quirk_x51_r1_r2 = {
.num_zones = 3,
- .hdmi_mux = 0.
+ .hdmi_mux = 0,
+ .amplifier = 0,
};
static struct quirk_entry quirk_x51_r3 = {
.num_zones = 4,
.hdmi_mux = 0,
+ .amplifier = 1,
};
static struct quirk_entry quirk_asm100 = {
.num_zones = 2,
.hdmi_mux = 1,
+ .amplifier = 0,
};
static int __init dmi_matched(const struct dmi_system_id *dmi)
@@ -147,7 +153,7 @@ struct wmax_brightness_args {
u32 percentage;
};
-struct hdmi_args {
+struct wmax_basic_args {
u8 arg;
};
@@ -232,16 +238,16 @@ static int alienware_update_led(struct platform_zone
*zone)
char *guid;
struct acpi_buffer input;
struct legacy_led_args legacy_args;
- struct wmax_led_args wmax_args;
+ struct wmax_led_args wmax_basic_args;
if (interface == WMAX) {
- wmax_args.led_mask = 1 << zone->location;
- wmax_args.colors = zone->colors;
- wmax_args.state = lighting_control_state;
+ wmax_basic_args.led_mask = 1 << zone->location;
+ wmax_basic_args.colors = zone->colors;
+ wmax_basic_args.state = lighting_control_state;
guid = WMAX_CONTROL_GUID;
method_id = WMAX_METHOD_ZONE_CONTROL;
- input.length = (acpi_size) sizeof(wmax_args);
- input.pointer = &wmax_args;
+ input.length = (acpi_size) sizeof(wmax_basic_args);
+ input.pointer = &wmax_basic_args;
} else {
legacy_args.colors = zone->colors;
legacy_args.brightness = global_brightness;
@@ -449,11 +455,7 @@ static void alienware_zone_exit(struct platform_device
*dev)
kfree(zone_attrs);
}
-/*
- The HDMI mux sysfs node indicates the status of the HDMI input mux.
- It can toggle between standard system GPU output and HDMI input.
-*/
-static acpi_status alienware_hdmi_command(struct hdmi_args *in_args,
+static acpi_status alienware_wmax_command(struct wmax_basic_args *in_args,
u32 command, int *out_data)
{
acpi_status status;
@@ -481,17 +483,21 @@ static acpi_status alienware_hdmi_command(struct
hdmi_args *in_args,
}
+/*
+ * The HDMI mux sysfs node indicates the status of the HDMI input mux.
+ * It can toggle between standard system GPU output and HDMI input.
+*/
static ssize_t show_hdmi_cable(struct device *dev,
struct device_attribute *attr, char *buf)
{
acpi_status status;
u32 out_data;
- struct hdmi_args in_args = {
+ struct wmax_basic_args in_args = {
.arg = 0,
};
status =
- alienware_hdmi_command(&in_args, WMAX_METHOD_HDMI_CABLE,
- (u32 *) & out_data);
+ alienware_wmax_command(&in_args, WMAX_METHOD_HDMI_CABLE,
+ (u32 *) &out_data);
if (ACPI_SUCCESS(status)) {
if (out_data == 0)
return scnprintf(buf, PAGE_SIZE,
@@ -509,12 +515,12 @@ static ssize_t show_hdmi_source(struct device *dev,
{
acpi_status status;
u32 out_data;
- struct hdmi_args in_args = {
+ struct wmax_basic_args in_args = {
.arg = 0,
};
status =
- alienware_hdmi_command(&in_args, WMAX_METHOD_HDMI_STATUS,
- (u32 *) & out_data);
+ alienware_wmax_command(&in_args, WMAX_METHOD_HDMI_STATUS,
+ (u32 *) &out_data);
if (ACPI_SUCCESS(status)) {
if (out_data == 1)
@@ -533,7 +539,7 @@ static ssize_t toggle_hdmi_source(struct device *dev,
const char *buf, size_t count)
{
acpi_status status;
- struct hdmi_args args;
+ struct wmax_basic_args
[PATCH 0/4] alienware-wmi new platform and feature support
I've got some extensions for the alienware-wmi driver that have been introduced for a few new platforms and can be controlled via the WMI interface. Mario Limonciello (4): Add support for new platform, X51-R3 Add support for alienware graphics amplifier Add support for deep sleep control. Add support for two new systems: ASM200 & ASM201 drivers/platform/x86/alienware-wmi.c | 285 +++ 1 file changed, 252 insertions(+), 33 deletions(-) -- 1.9.1
Re: [PATCH] base: isa: Remove X86_32 dependency
On 01/21/2016 06:47 PM, H. Peter Anvin wrote: > Well, and as you can see from the build robot because a lot of those > drivers simply don't compile on 64-bit systems. If nothing else you > would have to push the 32-bit tests downward in the config dependency tree. > > -hpa Yes, you're right. There doesn't appear to be anything 32-bit specific in the ISA bus driver itself, so these build failures must be due to configs relying on the 32-bit dependency from CONFIG_ISA. It should be possible to decouple the 32-bit dependency, so I'll work through the config dependency tree and fix the build errors with explicit CONFIG_X86_32 dependencies. I'll submit a new patch with those changes when complete. William Breathitt Gray
Re: [RFC 0/3] block: proportional based blk-throttling
Hi, On Thu, Jan 21, 2016 at 05:41:57PM -0500, Tejun Heo wrote: > Hello, Shaohua. > > On Thu, Jan 21, 2016 at 02:24:51PM -0800, Shaohua Li wrote: > > > Have you tried with some level, say 5, of nesting? IIRC, how it > > > implements hierarchical control is rather braindead (and yeah I'm > > > responsible for the damage). > > > > Not yet. Agree nesting increases the locking time. But my test is > > already an extreme case. I had 32 threads in 2 nodes running IO and the > > IOPS is 1M/s. Don't think real workload will act like this. The locking > > issue definitely should be revisited in the future though. > > The thing is that most of the possible contentions can be removed by > implementing per-cpu cache which shouldn't be too difficult. 10% > extra cost on current gen hardware is already pretty high. I did think about this. per-cpu cache does sound straightforward, but it could severely impact fairness. For example, we give each cpu a budget, see 1MB. If a cgroup doesn't use the 1M budget, we don't hold the lock. But if we have 128 CPUs, the cgroup can use 128 * 1M more budget, which breaks fairness very much. I have no idea how this can be fixed. > > Disagree io time is a better choice. Actually I think IO time will be > > If IO time isn't the right term, let's call it IO cost. Whatever the > term, the actual fraction of cost that each IO is incurring. > > > the least we shoule consider for SSD. Idealy if we know each IO cost and > > total disk capability, things will be easy. Unfortunately there is no > > way to know IO cost. Bandwidth isn't perfect, but might be the best. > > > > I don't know why you think devices are predictable. SSD is never > > predictable. I'm not sure how you will measure IO time. Morden SSD has > > large queue depth (blk-mq support 10k queue depth). That means we can > > send 10k IO in several ns. Measuring IO start/finish time doesn't help > > too. a 4k IO with 1 io depth might use 10us. a 4k IO with 100 io depth > > might use more than 100us. The IO time will increase with higher io > > depth. The fundamental problem is disk with large queue depth can buffer > > infinite IO request. I think IO time only works for queue depth 1 disk. > > They're way more predictable than rotational devices when measured > over a period. I don't think we'll be able to measure anything > meaningful at individual command level but aggregate numbers should be > fairly stable. A simple approximation of IO cost such as fixed cost > per IO + cost proportional to IO size would do a far better job than > just depending on bandwidth or iops and that requires approximating > two variables over time. I'm not sure how easy / feasible that > actually would be tho. It still sounds like IO time, otherwise I can't imagine we can measure the cost. If we use some sort of aggregate number, it likes a variation of bandwidth. eg cost = bandwidth/ios. I understand you probably want something like: get disk total resource, predicate resource of each IO, and then use the info to arbitrate cgroups. I don't know how it's possible. A disk which uses all its resources can still accept new IO queuing. Maybe someday a fancy device can export the info. Thanks, Shaohua
Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables
On 01/21/16 14:25, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 1:37 PM, Konrad Rzeszutek Wilk > wrote: >>> Sure, do we know if that ICC compatible? Do we care? There are a >>> series of ICC hacks put in place on ipxe's original solution which >>> I've folded in, it seems that works but if we care about ICC those >>> folks should perhaps help review as well. >> >> I didn't know the kernel could even be compiled with ICC? Thought >> only GCC worked? > > I'm happy with that, just wanted to make sure I raise the flag concern > given the icc hacks on the linker tables. > >> Anyhow - it may be that those fixes were for quite old ICC versions. >> Does the latest one manifest these oddities? > > I am not sure, I yield to Michael as the author of the original ICC > compatibility pieces. If we don't care about ICC let me know and I'll > just drop the stuff. In lack of such statements I'll just keep the > work arounds in place, but I'm more than trilled to drop it. > In general we let the ICC and Clang/LLVM teams communicate with out a post facto. We can't just guess what their requirements are, especially since they are likely to change between revisions. -hpa
[PATCH v2] usb: devio: Add ioctl to disallow detaching kernel USB drivers.
From: Reilly Grant
The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
relinquish the ability to issue other ioctls that may interfere with
other processes and drivers that have claimed an interface on the
device.
Signed-off-by: Reilly Grant
Signed-off-by: Emilio López
---
I guess code talks more than words :) This patch is only build-tested,
and is meant to showcase the approach. The basic idea is to allow
limiting the interface claims via an extra parameter to resolve
Krzysztof's worries.
A longer paragraph explaining the idea can be seen at
http://www.spinics.net/lists/linux-usb/msg135271.html
Cheers!
Emilio
Changes in v2:
- Added a parameter to the ioctl, a mask of interfaces an unprivileged
process is allowed to claim.
- Drop Tested-by's
drivers/usb/core/devio.c | 65 ---
include/uapi/linux/usbdevice_fs.h | 5 +++
2 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 38ae877c..bf40aa6 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -77,6 +77,8 @@ struct usb_dev_state {
unsigned long ifclaimed;
u32 secid;
u32 disabled_bulk_eps;
+ bool privileges_dropped;
+ unsigned long interface_allowed_mask;
};
struct async {
@@ -641,6 +643,14 @@ static int claimintf(struct usb_dev_state *ps, unsigned
int ifnum)
if (test_bit(ifnum, &ps->ifclaimed))
return 0;
+ if (ps->privileges_dropped) {
+ if (ifnum >= 8*sizeof(ps->interface_allowed_mask))
+ return -EINVAL;
+
+ if (!test_bit(ifnum, &ps->interface_allowed_mask))
+ return -EACCES;
+ }
+
intf = usb_ifnum_to_if(dev, ifnum);
if (!intf)
err = -ENOENT;
@@ -878,7 +888,7 @@ static int usbdev_open(struct inode *inode, struct file
*file)
int ret;
ret = -ENOMEM;
- ps = kmalloc(sizeof(struct usb_dev_state), GFP_KERNEL);
+ ps = kzalloc(sizeof(struct usb_dev_state), GFP_KERNEL);
if (!ps)
goto out_free_ps;
@@ -911,11 +921,8 @@ static int usbdev_open(struct inode *inode, struct file
*file)
INIT_LIST_HEAD(&ps->async_pending);
INIT_LIST_HEAD(&ps->async_completed);
init_waitqueue_head(&ps->wait);
- ps->discsignr = 0;
ps->disc_pid = get_pid(task_pid(current));
ps->cred = get_current_cred();
- ps->disccontext = NULL;
- ps->ifclaimed = 0;
security_task_getsecid(current, &ps->secid);
smp_wmb();
list_add_tail(&ps->list, &dev->filelist);
@@ -1215,6 +1222,27 @@ static int proc_connectinfo(struct usb_dev_state *ps,
void __user *arg)
static int proc_resetdevice(struct usb_dev_state *ps)
{
+ struct usb_host_config *actconfig = ps->dev->actconfig;
+ struct usb_interface *interface;
+ int i, number;
+
+ /* Don't touch the device if any interfaces are claimed. It
+* could interfere with other drivers' operations and this
+* process has dropped its privileges to do such things.
+*/
+ if (ps->privileges_dropped && actconfig) {
+ for (i = 0; i < actconfig->desc.bNumInterfaces; ++i) {
+ interface = actconfig->interface[i];
+ number =
interface->cur_altsetting->desc.bInterfaceNumber;
+ if (usb_interface_claimed(interface)) {
+ dev_warn(&ps->dev->dev,
+ "usbfs: interface %d claimed by %s
while '%s' resets device\n",
+ number, interface->dev.driver->name,
current->comm);
+ return -EACCES;
+ }
+ }
+ }
+
return usb_reset_device(ps->dev);
}
@@ -1922,6 +1950,9 @@ static int proc_ioctl(struct usb_dev_state *ps, struct
usbdevfs_ioctl *ctl)
struct usb_interface*intf = NULL;
struct usb_driver *driver = NULL;
+ if (ps->privileges_dropped)
+ return -EACCES;
+
/* alloc buffer */
size = _IOC_SIZE(ctl->ioctl_code);
if (size > 0) {
@@ -2074,6 +2105,9 @@ static int proc_disconnect_claim(struct usb_dev_state
*ps, void __user *arg)
if (intf->dev.driver) {
struct usb_driver *driver = to_usb_driver(intf->dev.driver);
+ if (ps->privileges_dropped)
+ return -EACCES;
+
if ((dc.flags & USBDEVFS_DISCONNECT_CLAIM_IF_DRIVER) &&
strncmp(dc.driver, intf->dev.driver->name,
sizeof(dc.driver)) != 0)
@@ -2130,6 +2164,26 @@ static int proc_free_streams(struct usb_dev_state *ps,
void __user *arg)
return r;
}
+static int proc_drop_privileges(struct usb_dev_state *ps, void __user *arg)
+{
+ s
Re: [PATCH 08/17] perf hists browser: Fix context menu item
Em Thu, Jan 21, 2016 at 01:07:10PM +0900, Namhyung Kim escreveu: > On Wed, Jan 20, 2016 at 09:52:45PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Sun, Jan 17, 2016 at 01:03:08AM +0900, Namhyung Kim escreveu: > > > When symbol sort key is not given, it doesn't show any item other than > > > exit. Check sort key to select possible items. Also check items more > > > strictly using sort key information. > > So, without this patch when I press enter on 'perf top' I can zoom into > > threads, with it I lose that option. > Yes, but it was incorrect information. The default sort key of 'perf > top' doesn't contain 'comm' (or 'pid') so hist entries it shows can > have samples from different threads. The result is that it only shows > thread of the first sample of the entry. Filtering based on this > incorrect info should be avoided IMHO. Ok, agreed, but this patch is doing way too many things at once, please take a look at my current perf/core branch, it has the first few patches I carved out from this one, see if you are ok with it, will continue. And this is not hierarchy related, so will go first, as fixes in perf/core. - Arnaldo
Re: [PATCH] base: isa: Remove X86_32 dependency
On 01/21/16 15:43, William Breathitt Gray wrote: > On 01/21/2016 02:40 PM, H. Peter Anvin wrote: >> CONFIG_ISA is mainly used to exclude drivers that are for ISA-specific >> devices. >> >> However, PC/104 is indeed an actual ISA parallel bus, and as you say >> widely used in embedded systems. However, I would like to see if there >> are anything hidden with !CONFIG_ISA which makes sense in PC104 systems. > > My ultimate objective is to be able to use the ISA bus driver > (drivers/base/isa.c). This driver is conditionally compiled based on > CONFIG_ISA, which in turn depends on CONFIG_X86_32. Up until now, I've > been using platform_driver for my non-hotpluggable PC/104 devices, but > it appears that isa_driver is more appropriate; unfortunately, I have > CONFIG_X86_64 set, which prevents the compilation of drivers/base/isa.c > due to the CONFIG_X86_32 dependency. > > I can alternatively create a patch to introduce a CONFIG_PC104 option. > This would allow the compilation of the ISA bus driver on either > CONFIG_ISA or CONFIG_PC104, thus allowing CONFIG_ISA to remain dependent > on CONFIG_X86_32. However, if the CONFIG_X86_32 dependency was > arbitrarily added to simply hide ISA functionality from newer > motherboards, perhaps the dependency should be removed. > Well, and as you can see from the build robot because a lot of those drivers simply don't compile on 64-bit systems. If nothing else you would have to push the 32-bit tests downward in the config dependency tree. -hpa
Re: [PATCH] base: isa: Remove X86_32 dependency
On 01/21/2016 02:40 PM, H. Peter Anvin wrote: > CONFIG_ISA is mainly used to exclude drivers that are for ISA-specific > devices. > > However, PC/104 is indeed an actual ISA parallel bus, and as you say > widely used in embedded systems. However, I would like to see if there > are anything hidden with !CONFIG_ISA which makes sense in PC104 systems. My ultimate objective is to be able to use the ISA bus driver (drivers/base/isa.c). This driver is conditionally compiled based on CONFIG_ISA, which in turn depends on CONFIG_X86_32. Up until now, I've been using platform_driver for my non-hotpluggable PC/104 devices, but it appears that isa_driver is more appropriate; unfortunately, I have CONFIG_X86_64 set, which prevents the compilation of drivers/base/isa.c due to the CONFIG_X86_32 dependency. I can alternatively create a patch to introduce a CONFIG_PC104 option. This would allow the compilation of the ISA bus driver on either CONFIG_ISA or CONFIG_PC104, thus allowing CONFIG_ISA to remain dependent on CONFIG_X86_32. However, if the CONFIG_X86_32 dependency was arbitrarily added to simply hide ISA functionality from newer motherboards, perhaps the dependency should be removed. William Breathitt Gray
RE: [PATCH 24/33] x86/kprobes: Get rid of kretprobe_trampoline_holder()
>From: Josh Poimboeuf [mailto:jpoim...@redhat.com]
>
>The kretprobe_trampoline_holder() wrapper around kretprobe_trampoline()
>isn't used anywhere and adds some unnecessary frame pointer instructions
>which never execute. Instead, just make kretprobe_trampoline() a proper
>ELF function.
>
Looks good to me :)
Acked-by: Masami Hiramatsu
Thanks!
>Signed-off-by: Josh Poimboeuf
>Cc: Ananth N Mavinakayanahalli
>Cc: Anil S Keshavamurthy
>Cc: "David S. Miller"
>Cc: Masami Hiramatsu
>---
> arch/x86/kernel/kprobes/core.c | 57 +-
> 1 file changed, 28 insertions(+), 29 deletions(-)
>
>diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
>index 1deffe6..5b187df 100644
>--- a/arch/x86/kernel/kprobes/core.c
>+++ b/arch/x86/kernel/kprobes/core.c
>@@ -671,38 +671,37 @@ NOKPROBE_SYMBOL(kprobe_int3_handler);
> * When a retprobed function returns, this code saves registers and
> * calls trampoline_handler() runs, which calls the kretprobe's handler.
> */
>-static void __used kretprobe_trampoline_holder(void)
>-{
>- asm volatile (
>- ".global kretprobe_trampoline\n"
>- "kretprobe_trampoline: \n"
>+asm(
>+ ".global kretprobe_trampoline\n"
>+ ".type kretprobe_trampoline, @function\n"
>+ "kretprobe_trampoline:\n"
> #ifdef CONFIG_X86_64
>- /* We don't bother saving the ss register */
>- " pushq %rsp\n"
>- " pushfq\n"
>- SAVE_REGS_STRING
>- " movq %rsp, %rdi\n"
>- " call trampoline_handler\n"
>- /* Replace saved sp with true return address. */
>- " movq %rax, 152(%rsp)\n"
>- RESTORE_REGS_STRING
>- " popfq\n"
>+ /* We don't bother saving the ss register */
>+ " pushq %rsp\n"
>+ " pushfq\n"
>+ SAVE_REGS_STRING
>+ " movq %rsp, %rdi\n"
>+ " call trampoline_handler\n"
>+ /* Replace saved sp with true return address. */
>+ " movq %rax, 152(%rsp)\n"
>+ RESTORE_REGS_STRING
>+ " popfq\n"
> #else
>- " pushf\n"
>- SAVE_REGS_STRING
>- " movl %esp, %eax\n"
>- " call trampoline_handler\n"
>- /* Move flags to cs */
>- " movl 56(%esp), %edx\n"
>- " movl %edx, 52(%esp)\n"
>- /* Replace saved flags with true return address. */
>- " movl %eax, 56(%esp)\n"
>- RESTORE_REGS_STRING
>- " popf\n"
>+ " pushf\n"
>+ SAVE_REGS_STRING
>+ " movl %esp, %eax\n"
>+ " call trampoline_handler\n"
>+ /* Move flags to cs */
>+ " movl 56(%esp), %edx\n"
>+ " movl %edx, 52(%esp)\n"
>+ /* Replace saved flags with true return address. */
>+ " movl %eax, 56(%esp)\n"
>+ RESTORE_REGS_STRING
>+ " popf\n"
> #endif
>- " ret\n");
>-}
>-NOKPROBE_SYMBOL(kretprobe_trampoline_holder);
>+ " ret\n"
>+ ".size kretprobe_trampoline, .-kretprobe_trampoline\n"
>+);
> NOKPROBE_SYMBOL(kretprobe_trampoline);
>
> /*
>--
>2.4.3
Re: [PATCH v7] fs: clear file privilege bits when mmap writing
On Thu, Jan 21, 2016 at 3:22 PM, Jann Horn wrote:
> On Mon, Jan 11, 2016 at 02:57:50PM -0800, Kees Cook wrote:
>> Normally, when a user can modify a file that has setuid or setgid bits,
>> those bits are cleared when they are not the file owner or a member
>> of the group. This is enforced when using write and truncate but not
>> when writing to a shared mmap on the file. This could allow the file
>> writer to gain privileges by changing a binary without losing the
>> setuid/setgid/caps bits.
>>
>> Changing the bits requires holding inode->i_mutex, so it cannot be done
>> during the page fault (due to mmap_sem being held during the fault). We
>> could do this during vm_mmap_pgoff, but that would need coverage in
>> mprotect as well, but to check for MAP_SHARED, we'd need to hold mmap_sem
>> again. We could clear at open() time, but it's possible things are
>> accidentally opening with O_RDWR and only reading. Better to clear on
>> close and error failures (i.e. an improvement over now, which is not
>> clearing at all).
>>
>> Instead, detect the need to clear the bits during the page fault, and
>> actually remove the bits during final fput. Since the file was open for
>> writing, it wouldn't have been possible to execute it yet (ETXTBSY).
>>
>> Signed-off-by: Kees Cook
>> ---
> [...]
>> diff --git a/fs/file_table.c b/fs/file_table.c
>> index ad17e05ebf95..ca11b86613cf 100644
>> --- a/fs/file_table.c
>> +++ b/fs/file_table.c
>> @@ -191,6 +191,21 @@ static void __fput(struct file *file)
>>
>> might_sleep();
>>
>> + /*
>> + * XXX: This is a delayed removal of privs (we've already been
>> + * written to), since we must avoid mmap_sem. But a race shouldn't
>> + * be possible since when open for writing, execve() will fail
>> + * with ETXTBSY (via deny_write_access()). A remaining problem
>> + * is that since we've already been written to, we must ignore the
>> + * return value of file_remove_privs(), since we can't reject the
>> + * writes of the past.
>> + */
>> + if (unlikely(file->f_flags & O_REMOVEPRIV)) {
>> + mutex_lock(&inode->i_mutex);
>> + file_remove_privs(file);
>> + mutex_unlock(&inode->i_mutex);
>> + }
>> +
>
> If there is any other setuid file I can run, can't I just do this?
>
> pid_t child = fork();
> if (child == 0) {
> /* fd will be 3 or so */
> int fd = open("setuid-file-with-bad-privs", O_WRONLY);
> char *ptr = mmap(..., fd, 0);
> memcpy(ptr, my_evil_code, sizeof(my_evil_code));
> /* su --bad-option just prints usage and exits, without touching
>* the fd - but since su has the last reference to the fd, __fput
>* will run with its privileges */
> execlp("su", "su", "--bad-option", NULL);
> }
> int status;
> wait(&status);
> execlp("setuid-file-with-bad-privs", "setuid-file-with-bad-privs", NULL);
>
> I think that file_remove_privs() really needs to be changed to use f_cred
> instead of current_cred(). That would also fix the known bypass where
> you pass the fd to a setuid process as fd 1, causing the setuid process
> to write more-or-less controlled data to a chosen offset, or similar
> stuff (see
> http://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/).
>
> Or was there already another patch that does this that I didn't see?
Andy brought it up as an issue, but I view it as a separate problem.
Both things need to be fixed. :)
-Kees
--
Kees Cook
Chrome OS & Brillo Security
Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init
Maybe a label attribute would help, I don't know. -hpa
Re: [PATCH] x86: static_cpu_has_safe: discard dynamic check after init
On 01/21/16 14:56, Borislav Petkov wrote: > > so this is silly: we're basically jumping after the JMP instruction > itself. So that will be the case on !X86_BUG_SYSRET_SS_ATTRS CPUs. > Still a two-byte and now even a useless JMP. > > The right thing to do would be to generate a NOP simply. > OK, so gcc isn't as clever as I thought. -hpa
Re: perf/ring-buffer: Undefined behaviour in kernel/events/ring_buffer.c:685:22
On 01/19/2016 09:31 AM, Peter Zijlstra wrote:
> On Sun, Jan 10, 2016 at 03:55:13PM -0500, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest, running the latest -next
>> kernel, I've hit the following warning:
>>
>> [ 3494.030114] UBSAN: Undefined behaviour in
>> kernel/events/ring_buffer.c:685:22
>> [ 3494.030647] shift exponent -1 is negative
>
> That's rb->page_order == -1, which should 'never' happen, curious!
>
> Funny though that rb::page_order is the exact field _after_ rb::work, ho
> humm.
>
I've tested your theory using:
diff --git a/kernel/events/internal.h b/kernel/events/internal.h
index 2bbad9c..f627a40 100644
--- a/kernel/events/internal.h
+++ b/kernel/events/internal.h
@@ -14,6 +14,7 @@ struct ring_buffer {
struct irq_work irq_work;
#ifdef CONFIG_PERF_USE_VMALLOC
struct work_struct work;
+ unsigned long dummy;
int page_order; /* allocation order */
#endif
int nr_pages; /* nr of data pages */
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index adfdc05..65346f8 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -682,6 +682,8 @@ void rb_free(struct ring_buffer *rb)
#else
static int data_page_nr(struct ring_buffer *rb)
{
+ if (page_order(rb) < 0 || rb->dummy)
+ pr_emerg("*** %lx\n", rb->dummy);
return rb->nr_pages << page_order(rb);
}
But the output I'm seeing indicates that dummy isn't corrupted:
[ 758.806091] *** 0
[ 758.806821]
[ 758.807961] UBSAN: Undefined behaviour in kernel/events/ring_buffer.c:687:22
[ 758.808833] shift exponent -1 is negative
[...]
Thanks,
Sasha
Re: [PATCH v7] fs: clear file privilege bits when mmap writing
On Mon, Jan 11, 2016 at 02:57:50PM -0800, Kees Cook wrote:
> Normally, when a user can modify a file that has setuid or setgid bits,
> those bits are cleared when they are not the file owner or a member
> of the group. This is enforced when using write and truncate but not
> when writing to a shared mmap on the file. This could allow the file
> writer to gain privileges by changing a binary without losing the
> setuid/setgid/caps bits.
>
> Changing the bits requires holding inode->i_mutex, so it cannot be done
> during the page fault (due to mmap_sem being held during the fault). We
> could do this during vm_mmap_pgoff, but that would need coverage in
> mprotect as well, but to check for MAP_SHARED, we'd need to hold mmap_sem
> again. We could clear at open() time, but it's possible things are
> accidentally opening with O_RDWR and only reading. Better to clear on
> close and error failures (i.e. an improvement over now, which is not
> clearing at all).
>
> Instead, detect the need to clear the bits during the page fault, and
> actually remove the bits during final fput. Since the file was open for
> writing, it wouldn't have been possible to execute it yet (ETXTBSY).
>
> Signed-off-by: Kees Cook
> ---
[...]
> diff --git a/fs/file_table.c b/fs/file_table.c
> index ad17e05ebf95..ca11b86613cf 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -191,6 +191,21 @@ static void __fput(struct file *file)
>
> might_sleep();
>
> + /*
> + * XXX: This is a delayed removal of privs (we've already been
> + * written to), since we must avoid mmap_sem. But a race shouldn't
> + * be possible since when open for writing, execve() will fail
> + * with ETXTBSY (via deny_write_access()). A remaining problem
> + * is that since we've already been written to, we must ignore the
> + * return value of file_remove_privs(), since we can't reject the
> + * writes of the past.
> + */
> + if (unlikely(file->f_flags & O_REMOVEPRIV)) {
> + mutex_lock(&inode->i_mutex);
> + file_remove_privs(file);
> + mutex_unlock(&inode->i_mutex);
> + }
> +
If there is any other setuid file I can run, can't I just do this?
pid_t child = fork();
if (child == 0) {
/* fd will be 3 or so */
int fd = open("setuid-file-with-bad-privs", O_WRONLY);
char *ptr = mmap(..., fd, 0);
memcpy(ptr, my_evil_code, sizeof(my_evil_code));
/* su --bad-option just prints usage and exits, without touching
* the fd - but since su has the last reference to the fd, __fput
* will run with its privileges */
execlp("su", "su", "--bad-option", NULL);
}
int status;
wait(&status);
execlp("setuid-file-with-bad-privs", "setuid-file-with-bad-privs", NULL);
I think that file_remove_privs() really needs to be changed to use f_cred
instead of current_cred(). That would also fix the known bypass where
you pass the fd to a setuid process as fd 1, causing the setuid process
to write more-or-less controlled data to a chosen offset, or similar
stuff (see
http://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/).
Or was there already another patch that does this that I didn't see?
signature.asc
Description: Digital signature
[GIT PULL] xfs: update #2 for 4.5-rc1
Hi Linus, Can you please pull the changes from the tag below? This is the second update for XFS that I mentioned in the original pull request last week. It contains a revert for a suspend regression in 4.4 and a fix for a long standing log recovery issue that has been further exposed by all the log recovery changes made in the original 4.5 merge. There is one more thing in this pull request - one that I forgot to merge into the origin. That is, pulling the XFS_IOC_FS[GS]ETXATTR ioctl up to the VFS level so that other filesystems can also use it for modifying project quota IDs. This allows the new ext4 project quota functionality to work with the XFs quota tools to manage project quotas, which means the ext4 project quota code can be tested against all the xfstests project quota tests that are written around xfs_quota. The original branch I posted has been used by Ted in the ext4 tree, so I have not modified it to add SOBs, etc. I've added those tags in the summary for the tag for this pull request, hence they shouldn't ever get lost. Thanks! -Dave. The following changes since commit dde7f55bd000696acc38296c21241971e1840142: Merge branch 'xfs-misc-fixes-for-4.5-2' into for-next (2016-01-12 07:04:30 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.5-2 for you to fetch changes up to ee3804d9f94c5a391c66386b70b9fe5a58775507: Merge branch 'xfs-misc-fixes-for-4.5-3' into for-next (2016-01-19 08:28:36 +1100) xfs: Update 2 for 4.5-rc1 This update contains: o promotion of XFS_IOC_FS[GS]ETXATTR ioctl to the vfs level so that it can be shared with other filesystems. The ext4 project quota functionality is the first target for this. The commits in this series have not been updated with review or final SOB tags because the branch they were originally published in was needed by ext4. Those tags are: Reviewed-by: Theodore Ts'o Signed-off-by: Dave Chinner o Revert a change that is causing suspend failures. o Fix a use-after-free that can occur on log mount failures. Been around forever, but now exposed by other changes to log recovery made in the first 4.5 merge. Dave Chinner (7): fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR promotion xfs: use FS_XFLAG definitions directly xfs: introduce per-inode DAX enablement Merge branch 'xfs-setxattr-promotion' into for-next Revert "xfs: clear PF_NOFREEZE for xfsaild kthread" xfs: log mount failures don't wait for buffers to be released Merge branch 'xfs-misc-fixes-for-4.5-3' into for-next fs/xfs/libxfs/xfs_format.h | 11 +- fs/xfs/libxfs/xfs_fs.h | 38 +- fs/xfs/xfs_buf.c | 10 + fs/xfs/xfs_inode.c | 60 ++--- fs/xfs/xfs_ioctl.c | 92 ++-- fs/xfs/xfs_iops.c |4 +- fs/xfs/xfs_trans_ail.c |1 - include/uapi/linux/fs.h| 33 8 files changed, 147 insertions(+), 102 deletions(-) -- Dave Chinner da...@fromorbit.com
Re: [PATCH v3] kallsyms: add support for relative offsets in kallsyms address table
On Thu, 21 Jan 2016 14:55:00 -0800 Kees Cook wrote: > IIUC, this means that the relocation work done after decompression now > doesn't have to do relocation updates for all these values, which > means a smaller relocation table as well. Makes sense, thanks. I altered the changelog : Similar to how relative extables are implemented, it is possible to : emit the kallsyms table in such a way that it contains offsets relative : to some anchor point in the kernel image rather than absolute : addresses. : : The benefit is that such table entries are no longer subject to dynamic : relocation when the build time so the relocation work done after : decompression now doesn't have to do relocation updates for all these : values, which means a smaller relocation table as well. : : Also, the runtime offsets of the kernel image are different. Also, on : 64-bit architectures, it essentially cuts the size of the address table : in half since offsets can typically be expressed in 32 bits. : : Since it is useful for some architectures (like x86) to retain the ability : to emit absolute values as well, this patch adds support for both, by : emitting absolute addresses as positive 32-bit values, and addresses : relative to the lowest encountered relative symbol as negative values, : which are subtracted from the runtime address of this base symbol to : produce the actual address. : : Support for the above is enabled by default for all architectures except : IA-64, whose symbols are too far apart to capture in this manner.
Re: [PATCH 0/2] Fix for ADJ_SETOFFSET w/ ADJ_NANO
On 01/21/2016 04:03 PM, John Stultz wrote: > David Herrmann mailed me pointing out that one of the > changes that landed in 4.5-rc broke users of ADJ_SETOFFSET > when used with ADJ_NANO. > > I've implemented a fix to this issue and also introduced > more unit tests to validate these going forward. > > Thomas: Can you queue the first patch for tip/timers/urgent? > > Shuah: The kselftests patch can wait to the next merge window > if you'd prefer. Yeah. Probably it has to wait until the next merge window as this is a new test. I can pull this into linux-kselftest next after merge window closes. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978
Re: [PATCH] mm,oom: Re-enable OOM killer using timers.
On Thu, 21 Jan 2016, Tetsuo Handa wrote: > I consider phases for managing system-wide OOM events as follows. > > (1) Design and use a system with appropriate memory capacity in mind. > > (2) When (1) failed, the OOM killer is invoked. The OOM killer selects > an OOM victim and allow that victim access to memory reserves by > setting TIF_MEMDIE to it. > > (3) When (2) did not solve the OOM condition, start allowing all tasks > access to memory reserves by your approach. > > (4) When (3) did not solve the OOM condition, start selecting more OOM > victims by my approach. > > (5) When (4) did not solve the OOM condition, trigger the kernel panic. > This was all mentioned previously, and I suggested that the panic only occur when memory reserves have been depleted, otherwise there is still the potential for the livelock to be solved. That is a patch that would apply today, before any of this work, since we never want to loop endlessly in the page allocator when memory reserves are fully depleted. This is all really quite simple.
Re: [PATCH v3 1/4] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string
On Thu, Jan 21, 2016 at 03:09:15PM +0800, Yuan Yao wrote: > new compatible string: "fsl,ls2080a-qspi". > > Signed-off-by: Yuan Yao > --- > Changed in v3: > Add the modifier for new compatible string like: > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi" > > Changed in v2: > Update my email to > --- > Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Acked-by: Rob Herring
Re: [PATCH, REGRESSION v3] mm: make apply_to_page_range more robust
On Thu, 21 Jan 2016, Mika Penttilä wrote: > Recent changes (4.4.0+) in module loader triggered oops on ARM : > > The module in question is in-tree module : > drivers/misc/ti-st/st_drv.ko > > The BUG is here : > > [ 53.638335] [ cut here ] > [ 53.642967] kernel BUG at mm/memory.c:1878! > [ 53.647153] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > [ 53.652987] Modules linked in: > [ 53.656061] CPU: 0 PID: 483 Comm: insmod Not tainted 4.4.0 #3 > [ 53.661808] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) > [ 53.668338] task: a989d400 ti: 9e6a2000 task.ti: 9e6a2000 > [ 53.673751] PC is at apply_to_page_range+0x204/0x224 > [ 53.678723] LR is at change_memory_common+0x90/0xdc > [ 53.683604] pc : [<800ca0ec>] lr : [<8001d668>] psr: 600b0013 > [ 53.683604] sp : 9e6a3e38 ip : 8001d6b4 fp : 7f0042fc > [ 53.695082] r10: r9 : 9e6a3e90 r8 : 0080 > [ 53.700309] r7 : r6 : 7f008000 r5 : 7f008000 r4 : 7f008000 > [ 53.706837] r3 : 8001d5a4 r2 : 7f008000 r1 : 7f008000 r0 : 80b8d3c0 > [ 53.713368] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > [ 53.720504] Control: 10c5387d Table: 2e6b804a DAC: 0055 > [ 53.726252] Process insmod (pid: 483, stack limit = 0x9e6a2210) > [ 53.732173] Stack: (0x9e6a3e38 to 0x9e6a4000) > [ 53.736532] 3e20: 7f007fff 7f008000 > [ 53.744714] 3e40: 80b8d3c0 80b8d3c0 7f007000 7f00426c 7f008000 > 7f008000 > [ 53.752895] 3e60: 7f004140 7f008000 0080 > 7f0042fc 8001d668 > [ 53.761076] 3e80: 9e6a3e90 8001d6b4 7f00426c 0080 > 9e6a3f58 7f004140 > [ 53.769257] 3ea0: 7f004240 7f00414c 8008bbe0 7f00 > > [ 53.777438] 3ec0: a8b12f00 0001cfd4 7f004250 7f004240 80b8159c > 00e0 7f0042fc > [ 53.785619] 3ee0: c183d000 74f8 18fd 0b3c > 7f002024 > [ 53.793800] 3f00: 0002 > > [ 53.801980] 3f20: 0040 > 0003 0001cfd4 > [ 53.810161] 3f40: 017b 8000f7e4 9e6a2000 0002 8008c498 > c183d000 74f8 > [ 53.818342] 3f60: c1841588 c1841409 c1842950 5000 52a0 > > [ 53.826523] 3f80: 0023 0024 001a 001e 0016 > > [ 53.834703] 3fa0: 003e3d60 8000f640 0003 0001cfd4 > 003e3d60 > [ 53.842884] 3fc0: 003e3d60 017b 003e3d20 7eabc9d4 > 76f2c000 0002 > [ 53.851065] 3fe0: 7eabc990 7eabc980 00016320 76e81d00 600b0010 0003 > > [ 53.859256] [<800ca0ec>] (apply_to_page_range) from [<8001d668>] > (change_memory_common+0x90/0xdc) > [ 53.868139] [<8001d668>] (change_memory_common) from [<8008bbe0>] > (load_module+0x194c/0x2068) > [ 53.876671] [<8008bbe0>] (load_module) from [<8008c498>] > (SyS_finit_module+0x64/0x74) > [ 53.884512] [<8008c498>] (SyS_finit_module) from [<8000f640>] > (ret_fast_syscall+0x0/0x34) > [ 53.892694] Code: e0834104 eabc e51a1008 eaac (e7f001f2) > [ 53.898792] ---[ end trace fe43fc78ebde29a3 ]--- > NACK to your patch as it is just covering up buggy code silently. The problem needs to be addressed in change_memory_common() to return if there is no size to change (numpages == 0). It's a two line fix to that function.
Re: [PATCH v3 2/4] Documentation: fsl-quadspi: Add fsl, ls2080a-qspi compatible string
On Thu, Jan 21, 2016 at 03:09:16PM +0800, Yuan Yao wrote: > new compatible string: "fsl,ls2080a-qspi". > > Signed-off-by: Yuan Yao > --- > Changed in v3: > Add the modifier for new compatible string like: > "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi" > > Changed in v2: > Update my email to > --- > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Acked-by: Rob Herring
Re: [PATCH v3 4/4] Documentation: fsl-quadspi: Add optional properties
On Thu, Jan 21, 2016 at 03:09:18PM +0800, Yuan Yao wrote: > Add optional properties for QSPI: > big-endian > if the register is big endian on this platform. > > Signed-off-by: Yuan Yao > --- > Changed in v3: > No changes. > > Changed in v2: > Update my email to > --- > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring
Re: [PATCH] Documentation: rockchip-dw-mshc: add RK3368 dw-mshc description
On Thu, Jan 21, 2016 at 08:32:09PM +0800, Shawn Lin wrote: > rk3368 dtsi file add dw-mshc compatible "rockchip,rk3368-dw-mshc" > but didn't add it into rockchip-dw-mshc.txt. > > Signed-off-by: Shawn Lin > --- > > Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring I'm assuming Heiko will take this. Rob
Re: [PATCH] raid6/algos.c : bug fix : Add the missing definitions to the pq.h file
On Thu, Jan 21, 2016 at 02:02:39PM -0800, Gayatri Kammela wrote: > Adding these pr_info and pr_err definitions so as to allow code to be > compiled successfully for testing in userspace, since the printk has > been replaced by pr_info and pr_err in algos.c > > Absence of these definitions result in the compilation errors > such as ' undefined reference to `pr_info' ' ' undefined reference to > `pr_err' ' > > Cc: NeilBrown > Cc: Anton Blanchard > Cc: Fenghua Yu > Signed-off-by: Gayatri Kammela > --- > include/linux/raid/pq.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h > index a7a06d1dcf9c..a0118d5929a9 100644 > --- a/include/linux/raid/pq.h > +++ b/include/linux/raid/pq.h > @@ -152,6 +152,8 @@ void raid6_dual_recov(int disks, size_t bytes, int faila, > int failb, > > # define jiffies raid6_jiffies() > # define printk printf > +# define pr_err(format, ...) fprintf(stderr, format, ## __VA_ARGS__) > +# define pr_info(format, ...) fprintf(stdout, format, ## __VA_ARGS__) > # define GFP_KERNEL 0 > # define __get_free_pages(x, y) ((unsigned long)mmap(NULL, PAGE_SIZE << > (y), \ >PROT_READ|PROT_WRITE, \ Applied, thanks!
[PATCH 2/2] kselftests: timers: Add adjtimex SETOFFSET validity tests
Add some simple tests to check both valid and invalid
offsets when using adjtimex's ADJ_SETOFFSET method.
Cc: Sasha Levin
Cc: Richard Cochran
Cc: Thomas Gleixner
Cc: Prarit Bhargava
Cc: Harald Hoyer
Cc: Kay Sievers
Cc: David Herrmann
Cc: Shuah Khan
Signed-off-by: John Stultz
---
tools/testing/selftests/timers/valid-adjtimex.c | 139 +++-
1 file changed, 138 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/timers/valid-adjtimex.c
b/tools/testing/selftests/timers/valid-adjtimex.c
index e86d937..60fe3c5 100644
--- a/tools/testing/selftests/timers/valid-adjtimex.c
+++ b/tools/testing/selftests/timers/valid-adjtimex.c
@@ -45,7 +45,17 @@ static inline int ksft_exit_fail(void)
}
#endif
-#define NSEC_PER_SEC 10L
+#define NSEC_PER_SEC 10LL
+#define USEC_PER_SEC 100LL
+
+#define ADJ_SETOFFSET 0x0100
+
+#include
+static int clock_adjtime(clockid_t id, struct timex *tx)
+{
+ return syscall(__NR_clock_adjtime, id, tx);
+}
+
/* clear NTP time_status & time_state */
int clear_time_state(void)
@@ -193,10 +203,137 @@ out:
}
+int set_offset(long long offset, int use_nano)
+{
+ struct timex tmx = {};
+ int ret;
+
+ tmx.modes = ADJ_SETOFFSET;
+ if (use_nano) {
+ tmx.modes |= ADJ_NANO;
+
+ tmx.time.tv_sec = offset / NSEC_PER_SEC;
+ tmx.time.tv_usec = offset % NSEC_PER_SEC;
+
+ if (offset < 0 && tmx.time.tv_usec) {
+ tmx.time.tv_sec -= 1;
+ tmx.time.tv_usec += NSEC_PER_SEC;
+ }
+ } else {
+ tmx.time.tv_sec = offset / USEC_PER_SEC;
+ tmx.time.tv_usec = offset % USEC_PER_SEC;
+
+ if (offset < 0 && tmx.time.tv_usec) {
+ tmx.time.tv_sec -= 1;
+ tmx.time.tv_usec += USEC_PER_SEC;
+ }
+ }
+
+ ret = clock_adjtime(CLOCK_REALTIME, &tmx);
+ if (ret < 0) {
+ printf("(sec: %ld usec: %ld) ", tmx.time.tv_sec,
tmx.time.tv_usec);
+ printf("[FAIL]\n");
+ return -1;
+ }
+ return 0;
+}
+
+int set_bad_offset(long sec, long usec, int use_nano)
+{
+ struct timex tmx = {};
+ int ret;
+
+ tmx.modes = ADJ_SETOFFSET;
+ if (use_nano)
+ tmx.modes |= ADJ_NANO;
+
+ tmx.time.tv_sec = sec;
+ tmx.time.tv_usec = usec;
+ ret = clock_adjtime(CLOCK_REALTIME, &tmx);
+ if (ret >= 0) {
+ printf("Invalid (sec: %ld usec: %ld) did not fail! ",
tmx.time.tv_sec, tmx.time.tv_usec);
+ printf("[FAIL]\n");
+ return -1;
+ }
+ return 0;
+}
+
+int validate_set_offset(void)
+{
+ printf("Testing ADJ_SETOFFSET... ");
+
+ /* Test valid values */
+ if (set_offset(NSEC_PER_SEC - 1, 1))
+ return -1;
+
+ if (set_offset(-NSEC_PER_SEC + 1, 1))
+ return -1;
+
+ if (set_offset(-NSEC_PER_SEC - 1, 1))
+ return -1;
+
+ if (set_offset(5 * NSEC_PER_SEC, 1))
+ return -1;
+
+ if (set_offset(-5 * NSEC_PER_SEC, 1))
+ return -1;
+
+ if (set_offset(5 * NSEC_PER_SEC + NSEC_PER_SEC / 2, 1))
+ return -1;
+
+ if (set_offset(-5 * NSEC_PER_SEC - NSEC_PER_SEC / 2, 1))
+ return -1;
+
+ if (set_offset(USEC_PER_SEC - 1, 0))
+ return -1;
+
+ if (set_offset(-USEC_PER_SEC + 1, 0))
+ return -1;
+
+ if (set_offset(-USEC_PER_SEC - 1, 0))
+ return -1;
+
+ if (set_offset(5 * USEC_PER_SEC, 0))
+ return -1;
+
+ if (set_offset(-5 * USEC_PER_SEC, 0))
+ return -1;
+
+ if (set_offset(5 * USEC_PER_SEC + USEC_PER_SEC / 2, 0))
+ return -1;
+
+ if (set_offset(-5 * USEC_PER_SEC - USEC_PER_SEC / 2, 0))
+ return -1;
+
+ /* Test invalid values */
+ if (set_bad_offset(0, -1, 1))
+ return -1;
+ if (set_bad_offset(0, -1, 0))
+ return -1;
+ if (set_bad_offset(0, 2 * NSEC_PER_SEC, 1))
+ return -1;
+ if (set_bad_offset(0, 2 * USEC_PER_SEC, 0))
+ return -1;
+ if (set_bad_offset(0, NSEC_PER_SEC, 1))
+ return -1;
+ if (set_bad_offset(0, USEC_PER_SEC, 0))
+ return -1;
+ if (set_bad_offset(0, -NSEC_PER_SEC, 1))
+ return -1;
+ if (set_bad_offset(0, -USEC_PER_SEC, 0))
+ return -1;
+
+ printf("[OK]\n");
+ return 0;
+}
+
int main(int argc, char **argv)
{
if (validate_freq())
return ksft_exit_fail();
+ if (validate_set_offset())
+ return ksft_exit_fail();
+
return ksft_exit_pass();
}
--
1.9.1
[PATCH 0/2] Fix for ADJ_SETOFFSET w/ ADJ_NANO
David Herrmann mailed me pointing out that one of the changes that landed in 4.5-rc broke users of ADJ_SETOFFSET when used with ADJ_NANO. I've implemented a fix to this issue and also introduced more unit tests to validate these going forward. Thomas: Can you queue the first patch for tip/timers/urgent? Shuah: The kselftests patch can wait to the next merge window if you'd prefer. Let me know if you have any thoughts or objections! thanks -john Cc: Sasha Levin Cc: Richard Cochran Cc: Thomas Gleixner Cc: Prarit Bhargava Cc: Harald Hoyer Cc: Kay Sievers Cc: David Herrmann Cc: Shuah Khan John Stultz (2): ntp: Fix ADJ_SETOFFSET being used w/ ADJ_NANO kselftests: timers: Add adjtimex SETOFFSET validity tests kernel/time/ntp.c | 14 ++- tools/testing/selftests/timers/valid-adjtimex.c | 139 +++- 2 files changed, 150 insertions(+), 3 deletions(-) -- 1.9.1
[PATCH 1/2] ntp: Fix ADJ_SETOFFSET being used w/ ADJ_NANO
Recently, in commit 37cf4dc3370f
("time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow")
I forgot to check if the timeval being passed was actually a
timespec (as is signaled with ADJ_NANO).
This resulted in that patch breaking ADJ_SETOFFSET users who set
ADJ_NANO, by rejecting valid timespecs that were compared with
valid timeval ranges.
This patch addresses this by checking for the ADJ_NANO flag and
using the timepsec check instead in that case.
Cc: Sasha Levin
Cc: Richard Cochran
Cc: Thomas Gleixner
Cc: Prarit Bhargava
Cc: Harald Hoyer
Cc: Kay Sievers
Cc: David Herrmann
Reported-by: Harald Hoyer
Reported-by: Kay Sievers
Signed-off-by: John Stultz
---
kernel/time/ntp.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 36f2ca0..6df8927 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -685,8 +685,18 @@ int ntp_validate_timex(struct timex *txc)
if (!capable(CAP_SYS_TIME))
return -EPERM;
- if (!timeval_inject_offset_valid(&txc->time))
- return -EINVAL;
+ if (txc->modes & ADJ_NANO) {
+ struct timespec ts;
+
+ ts.tv_sec = txc->time.tv_sec;
+ ts.tv_nsec = txc->time.tv_usec;
+ if (!timespec_inject_offset_valid(&ts))
+ return -EINVAL;
+
+ } else {
+ if (!timeval_inject_offset_valid(&txc->time))
+ return -EINVAL;
+ }
}
/*
--
1.9.1
[git pull] more vfs.git stuff
[trying to use git request-pull; result looks more or less sane, AFAICT...] Embarrassing braino fix + pipe page accounting + fixing an eyesore in find_filesystem() (checking that s1 is equal to prefix of s2 of given length can be done in many ways, but "compare strlen(s1) with length and then do strncmp()" is not a good one...) The following changes since commit c7b6c5fe67d1519759de2014a2c44f50fb1426f3: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2016-01-15 12:41:32 -0800) are available in the git repository at: gitol...@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to 117aa41e8020fe493bbb677ebe828c3a4b380185: [regression] fix braino in fs/dlm/user.c (2016-01-21 17:45:15 -0500) Al Viro (2): find_filesystem(): simplify comparison [regression] fix braino in fs/dlm/user.c Willy Tarreau (1): pipe: limit the per-user amount of pages allocated in pipes Documentation/sysctl/fs.txt | 23 ++ fs/dlm/user.c | 2 +- fs/filesystems.c| 6 +++--- fs/pipe.c | 47 +++-- include/linux/pipe_fs_i.h | 4 include/linux/sched.h | 1 + kernel/sysctl.c | 14 ++ 7 files changed, 91 insertions(+), 6 deletions(-)
[PATCH 25/33] x86/kvm: Set ELF function type for fastop functions
The callable functions created with the FOP* and FASTOP* macros are
missing ELF function annotations, which confuses tools like stacktool.
Properly annotate them.
This adds some additional labels to the assembly, but the generated
binary code is unchanged (with the exception of instructions which have
embedded references to __LINE__).
Signed-off-by: Josh Poimboeuf
Cc: Gleb Natapov
Cc: Paolo Bonzini
Cc: k...@vger.kernel.org
---
arch/x86/kvm/emulate.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 1505587..aa4d726 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -309,23 +309,29 @@ static void invalidate_registers(struct x86_emulate_ctxt
*ctxt)
static int fastop(struct x86_emulate_ctxt *ctxt, void (*fop)(struct fastop *));
-#define FOP_ALIGN ".align " __stringify(FASTOP_SIZE) " \n\t"
+#define FOP_FUNC(name) \
+ ".align " __stringify(FASTOP_SIZE) " \n\t" \
+ ".type " name ", @function \n\t" \
+ name ":\n\t"
+
#define FOP_RET "ret \n\t"
#define FOP_START(op) \
extern void em_##op(struct fastop *fake); \
asm(".pushsection .text, \"ax\" \n\t" \
".global em_" #op " \n\t" \
-FOP_ALIGN \
- "em_" #op ": \n\t"
+ FOP_FUNC("em_" #op)
#define FOP_END \
".popsection")
-#define FOPNOP() FOP_ALIGN FOP_RET
+#define FOPNOP() \
+ FOP_FUNC(__stringify(__UNIQUE_ID(nop))) \
+ FOP_RET
#define FOP1E(op, dst) \
- FOP_ALIGN "10: " #op " %" #dst " \n\t" FOP_RET
+ FOP_FUNC(#op "_" #dst) \
+ "10: " #op " %" #dst " \n\t" FOP_RET
#define FOP1EEX(op, dst) \
FOP1E(op, dst) _ASM_EXTABLE(10b, kvm_fastop_exception)
@@ -357,7 +363,8 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void
(*fop)(struct fastop *));
FOP_END
#define FOP2E(op, dst, src) \
- FOP_ALIGN #op " %" #src ", %" #dst " \n\t" FOP_RET
+ FOP_FUNC(#op "_" #dst "_" #src) \
+ #op " %" #src ", %" #dst " \n\t" FOP_RET
#define FASTOP2(op) \
FOP_START(op) \
@@ -395,7 +402,8 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void
(*fop)(struct fastop *));
FOP_END
#define FOP3E(op, dst, src, src2) \
- FOP_ALIGN #op " %" #src2 ", %" #src ", %" #dst " \n\t" FOP_RET
+ FOP_FUNC(#op "_" #dst "_" #src "_" #src2) \
+ #op " %" #src2 ", %" #src ", %" #dst " \n\t" FOP_RET
/* 3-operand, word-only, src2=cl */
#define FASTOP3WCL(op) \
@@ -407,7 +415,12 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void
(*fop)(struct fastop *));
FOP_END
/* Special case for SETcc - 1 instruction per cc */
-#define FOP_SETCC(op) ".align 4; " #op " %al; ret \n\t"
+#define FOP_SETCC(op) \
+ ".align 4 \n\t" \
+ ".type " #op ", @function \n\t" \
+ #op ": \n\t" \
+ #op " %al \n\t" \
+ FOP_RET
asm(".global kvm_fastop_exception \n"
"kvm_fastop_exception: xor %esi, %esi; ret");
--
2.4.3
[PATCH 02/33] kbuild/stacktool: Add CONFIG_STACK_VALIDATION option
Add a CONFIG_STACK_VALIDATION option which will run "stacktool check"
for each .o file to ensure the validity of its stack metadata.
Signed-off-by: Josh Poimboeuf
---
Makefile | 5 -
arch/Kconfig | 6 ++
lib/Kconfig.debug | 12
scripts/Makefile.build | 38 ++
scripts/mod/Makefile | 2 ++
5 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 70dea02..8e518fe 100644
--- a/Makefile
+++ b/Makefile
@@ -986,7 +986,10 @@ prepare0: archprepare FORCE
$(Q)$(MAKE) $(build)=.
# All the preparing..
-prepare: prepare0
+prepare: prepare0 prepare-stacktool
+
+PHONY += prepare-stacktool
+prepare-stacktool: $(if $(CONFIG_STACK_VALIDATION), tools/stacktool FORCE)
# Generate some files
# ---
diff --git a/arch/Kconfig b/arch/Kconfig
index 671810c..b20f472 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -527,6 +527,12 @@ config HAVE_COPY_THREAD_TLS
normal C parameter passing, rather than extracting the syscall
argument from pt_regs.
+config HAVE_STACK_VALIDATION
+ bool
+ help
+ Architecture supports the stacktool host tool, which adds
+ compile-time stack metadata validation.
+
#
# ABI hall of shame
#
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ee1ac1c..a984656 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -342,6 +342,18 @@ config FRAME_POINTER
larger and slower, but it gives very useful debugging information
in case of kernel bugs. (precise oopses/stacktraces/warnings)
+config STACK_VALIDATION
+ bool "Enable compile-time stack metadata validation"
+ depends on HAVE_STACK_VALIDATION
+ default n
+ help
+ Add compile-time checks to validate stack metadata, including frame
+ pointers (if CONFIG_FRAME_POINTER is enabled). This helps ensure
+ that runtime stack traces are more reliable.
+
+ For more information, see
+ tools/stacktool/Documentation/stack-validation.txt.
+
config DEBUG_FORCE_WEAK_PER_CPU
bool "Force weak per-cpu definitions"
depends on DEBUG_KERNEL
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 01df30a..5ec40fc 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -241,10 +241,31 @@ cmd_record_mcount =
\
fi;
endif
+ifdef CONFIG_STACK_VALIDATION
+
+__stacktool_obj := $(objtree)/tools/stacktool/stacktool
+
+stacktool_args = check
+ifndef CONFIG_FRAME_POINTER
+stacktool_args += --no-fp
+endif
+
+# Set STACKTOOL_foo.o=n to skip stack metadata validation for a file.
+# Set STACKTOOL=n to skip stack metadata validation for a directory.
+stacktool_obj = $(if $(patsubst n%,, \
+ $(STACKTOOL_$(basetarget).o)$(STACKTOOL)y), \
+ $(__stacktool_obj))
+cmd_stacktool = $(if $(patsubst n%,, \
+ $(STACKTOOL_$(basetarget).o)$(STACKTOOL)y), \
+ $(__stacktool_obj) $(stacktool_args) "$(@)";)
+
+endif # CONFIG_STACK_VALIDATION
+
define rule_cc_o_c
$(call echo-cmd,checksrc) $(cmd_checksrc) \
$(call echo-cmd,cc_o_c) $(cmd_cc_o_c);\
$(cmd_modversions)\
+ $(cmd_stacktool) \
$(call echo-cmd,record_mcount)\
$(cmd_record_mcount) \
scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >\
@@ -253,14 +274,23 @@ define rule_cc_o_c
mv -f $(dot-target).tmp $(dot-target).cmd
endef
+define rule_as_o_S
+ $(call echo-cmd,as_o_S) $(cmd_as_o_S);\
+ $(cmd_stacktool) \
+ scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,as_o_S)' >\
+ $(dot-target).tmp; \
+ rm -f $(depfile); \
+ mv -f $(dot-target).tmp $(dot-target).cmd
+endef
+
# Built-in and composite module parts
-$(obj)/%.o: $(src)/%.c $(recordmcount_source) FORCE
+$(obj)/%.o: $(src)/%.c $(recordmcount_source) $(stacktool_obj) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
# Single-part modules are special since we need to mark them in $(MODVERDIR)
-$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) FORCE
+$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source)
$(stacktool_obj) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; } > $(MODVERDIR)/$(@F:.o=.mod)
@@ -290,8 +320,8 @@ $(obj)/%.s: $(src)/%.S FORCE
quiet_cmd_as_o_S = AS $(quiet_modtag) $@
cmd_as_o_S
Re: [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL.
On 01/21/2016 04:29 AM, Ding Tianhong wrote:
I build a script to create several process for ioctl loop calling,
the ioctl will calling the kernel function just like:
xx_ioctl {
...
rtnl_lock();
function();
rtnl_unlock();
...
}
The function may sleep several ms, but will not halt, at the same time
another user service may calling ifconfig to change the state of the
ethernet, and after several hours, the hung task thread report this problem:
149738.039038] INFO: task ifconfig:11890 blocked for more than 120 seconds.
[149738.040597] "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[149738.042280] ifconfig D 88061ec13680 0 11890 11573 0x0080
[149738.042284] 88052449bd40 0082 88053a33f300
88052449bfd8
[149738.042286] 88052449bfd8 88052449bfd8 88053a33f300
819e6240
[149738.042288] 819e6244 88053a33f300
819e6248
[149738.042290] Call Trace:
[149738.042300] [] schedule_preempt_disabled+0x29/0x70
[149738.042303] [] __mutex_lock_slowpath+0xc5/0x1c0
[149738.042305] [] mutex_lock+0x1f/0x2f
[149738.042309] [] rtnl_lock+0x15/0x20
[149738.042311] [] dev_ioctl+0xda/0x590
[149738.042314] [] ? __do_page_fault+0x21c/0x560
[149738.042318] [] sock_do_ioctl+0x45/0x50
[149738.042320] [] sock_ioctl+0x1f0/0x2c0
[149738.042324] [] do_vfs_ioctl+0x2e5/0x4c0
[149738.042327] [] ? fget_light+0xa0/0xd0
cut here
I got the vmcore and found that the ifconfig is already in the wait_list of the
rtnl_lock for 120 second, but my process could get and release the rtnl_lock
normally several times in one second, so it means that my process jump the
queue and the ifconfig couldn't get the rtnl all the time, I check the mutex
lock
slow path and found that the mutex may spin on owner ignore whether the wait
list
is empty, it will cause the task in the wait list always be cut in line, so add
test for wait list in the mutex_can_spin_on_owner and avoid this problem.
Signed-off-by: Ding Tianhong
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Davidlohr Bueso
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Jason Low
Cc: Tim Chen
Cc: Waiman Long
---
kernel/locking/mutex.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 0551c21..596b341 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -256,7 +256,7 @@ static inline int mutex_can_spin_on_owner(struct mutex
*lock)
struct task_struct *owner;
int retval = 1;
- if (need_resched())
+ if (need_resched() || atomic_read(&lock->count) == -1)
return 0;
rcu_read_lock();
@@ -283,10 +283,11 @@ static inline bool mutex_try_to_acquire(struct mutex
*lock)
/*
* Optimistic spinning.
*
- * We try to spin for acquisition when we find that the lock owner
- * is currently running on a (different) CPU and while we don't
- * need to reschedule. The rationale is that if the lock owner is
- * running, it is likely to release the lock soon.
+ * We try to spin for acquisition when we find that there are no
+ * pending waiters and the lock owner is currently running on a
+ * (different) CPU and while we don't need to reschedule. The
+ * rationale is that if the lock owner is running, it is likely
+ * to release the lock soon.
*
* Since this needs the lock owner, and this mutex implementation
* doesn't track the owner atomically in the lock field, we need to
This patch will largely defeat the performance benefit of optimistic
spinning. I have an alternative solution to this live-lock problem.
Would you mind trying out the attached patch to see if it can fix your
problem?
Cheers,
Longman
From 1bbb5a4434d395f48163abc5435c5c720a15d327 Mon Sep 17 00:00:00 2001
From: Waiman Long
Date: Thu, 21 Jan 2016 17:53:14 -0500
Subject: [PATCH] locking/mutex: Enable optimistic spinning of woken task in
wait list
Ding Tianhong reported a live-lock situation where a constant stream
of incoming optimistic spinners blocked a task in the wait list from
getting the mutex.
This patch attempts to fix this live-lock condition by enabling the
a woken task in the wait list to enter optimistic spinning loop itself
with precedence over the ones in the OSQ. This should prevent the
live-lock
condition from happening.
Signed-off-by: Waiman Long
---
include/linux/mutex.h |2 +
kernel/locking/mutex.c | 95 +++-
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 2cb7531..2c55ecd 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -57,6 +57,8 @@ struct mutex {
#endif
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
struct optimistic_spin_queue osq; /* Spinner MCS lock */
+
[PATCH 06/33] x86/asm/xen: Set ELF function type for xen_adjust_exception_frame()
xen_adjust_exception_frame() is a callable function, but is missing the ELF function type, which confuses tools like stacktool. Properly annotate it to be a callable function. The generated code is unchanged. Signed-off-by: Josh Poimboeuf Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: David Vrabel --- arch/x86/xen/xen-asm_64.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index cc8acc4..c3df431 100644 --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -26,6 +26,7 @@ ENTRY(xen_adjust_exception_frame) mov 8+0(%rsp), %rcx mov 8+8(%rsp), %r11 ret $16 +ENDPROC(xen_adjust_exception_frame) hypercall_iret = hypercall_page + __HYPERVISOR_iret * 32 /* -- 2.4.3
[PATCH 05/33] x86/xen: Add stack frame dependency to hypercall inline asm calls
If a hypercall is inlined at the beginning of a function, gcc can insert
the call instruction before setting up a stack frame, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace.
Force a stack frame to be created if CONFIG_FRAME_POINTER is enabled by
listing the stack pointer as an output operand for the hypercall inline
asm statements.
Signed-off-by: Josh Poimboeuf
Reviewed-by: David Vrabel
Reviewed-by: Borislav Petkov
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
---
arch/x86/include/asm/xen/hypercall.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index 3bcdcc8..a12a047 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -110,9 +110,10 @@ extern struct { char _entry[32]; } hypercall_page[];
register unsigned long __arg2 asm(__HYPERCALL_ARG2REG) = __arg2; \
register unsigned long __arg3 asm(__HYPERCALL_ARG3REG) = __arg3; \
register unsigned long __arg4 asm(__HYPERCALL_ARG4REG) = __arg4; \
- register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5;
+ register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5; \
+ register void *__sp asm(_ASM_SP);
-#define __HYPERCALL_0PARAM "=r" (__res)
+#define __HYPERCALL_0PARAM "=r" (__res), "+r" (__sp)
#define __HYPERCALL_1PARAM __HYPERCALL_0PARAM, "+r" (__arg1)
#define __HYPERCALL_2PARAM __HYPERCALL_1PARAM, "+r" (__arg2)
#define __HYPERCALL_3PARAM __HYPERCALL_2PARAM, "+r" (__arg3)
--
2.4.3
[PATCH 07/33] x86/asm/xen: Create stack frames in xen-asm.S
xen_irq_enable_direct(), xen_restore_fl_direct(), and check_events() are callable non-leaf functions which don't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create stack frames for them when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: David Vrabel --- arch/x86/xen/xen-asm.S | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S index 3e45aa0..eff224d 100644 --- a/arch/x86/xen/xen-asm.S +++ b/arch/x86/xen/xen-asm.S @@ -14,6 +14,7 @@ #include #include #include +#include #include "xen-asm.h" @@ -23,6 +24,7 @@ * then enter the hypervisor to get them handled. */ ENTRY(xen_irq_enable_direct) + FRAME_BEGIN /* Unmask events */ movb $0, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask @@ -39,6 +41,7 @@ ENTRY(xen_irq_enable_direct) 2: call check_events 1: ENDPATCH(xen_irq_enable_direct) + FRAME_END ret ENDPROC(xen_irq_enable_direct) RELOC(xen_irq_enable_direct, 2b+1) @@ -82,6 +85,7 @@ ENDPATCH(xen_save_fl_direct) * enters the hypervisor to get them delivered if so. */ ENTRY(xen_restore_fl_direct) + FRAME_BEGIN #ifdef CONFIG_X86_64 testw $X86_EFLAGS_IF, %di #else @@ -100,6 +104,7 @@ ENTRY(xen_restore_fl_direct) 2: call check_events 1: ENDPATCH(xen_restore_fl_direct) + FRAME_END ret ENDPROC(xen_restore_fl_direct) RELOC(xen_restore_fl_direct, 2b+1) @@ -109,7 +114,8 @@ ENDPATCH(xen_restore_fl_direct) * Force an event check by making a hypercall, but preserve regs * before making the call. */ -check_events: +ENTRY(check_events) + FRAME_BEGIN #ifdef CONFIG_X86_32 push %eax push %ecx @@ -139,4 +145,6 @@ check_events: pop %rcx pop %rax #endif + FRAME_END ret +ENDPROC(check_events) -- 2.4.3
[PATCH 04/33] x86/stacktool: Add STACKTOOL_IGNORE_FUNC macro
Add a new stacktool ignore macro, STACKTOOL_IGNORE_FUNC, which can be
used to tell stacktool to skip validation of a function.
Signed-off-by: Josh Poimboeuf
---
MAINTAINERS | 1 +
arch/x86/kernel/vmlinux.lds.S | 5 -
include/linux/stacktool.h | 23 +++
3 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 include/linux/stacktool.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ecbea9..80b26ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10190,6 +10190,7 @@ STACK METADATA VALIDATION
M: Josh Poimboeuf
S: Supported
F: tools/stacktool/
+F: include/linux/stacktool.h
STAGING SUBSYSTEM
M: Greg Kroah-Hartman
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 4f19942..c08c283c 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -333,7 +333,10 @@ SECTIONS
/* Sections to be discarded */
DISCARDS
- /DISCARD/ : { *(.eh_frame) }
+ /DISCARD/ : {
+ *(.eh_frame)
+ *(__stacktool_ignore_*)
+ }
}
diff --git a/include/linux/stacktool.h b/include/linux/stacktool.h
new file mode 100644
index 000..0d90db7
--- /dev/null
+++ b/include/linux/stacktool.h
@@ -0,0 +1,23 @@
+#ifndef _LINUX_STACKTOOL_H
+#define _LINUX_STACKTOOL_H
+
+#ifdef CONFIG_STACK_VALIDATION
+/*
+ * This C macro tells stacktool to ignore the function when doing stack
+ * metadata validation. It should only be used in special cases where you're
+ * 100% sure it won't affect the reliability of frame pointers and kernel stack
+ * traces.
+ *
+ * For more information, see
tools/stacktool/Documentation/stack-validation.txt.
+ */
+#define STACKTOOL_IGNORE_FUNC(_func) \
+ static void __used __section(__stacktool_ignore_func) \
+ *__stacktool_ignore_func_##_func = _func
+
+#else /* !CONFIG_STACK_VALIDATION */
+
+#define STACKTOOL_IGNORE_FUNC(_func)
+
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* _LINUX_STACKTOOL_H */
--
2.4.3
[PATCH 17/33] x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
do_suspend_lowlevel() is a callable non-leaf function which doesn't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create a stack frame for it when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf Acked-by: Pavel Machek Acked-by: Rafael J. Wysocki Reviewed-by: Borislav Petkov Cc: Len Brown --- arch/x86/kernel/acpi/wakeup_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S index 8c35df4..169963f 100644 --- a/arch/x86/kernel/acpi/wakeup_64.S +++ b/arch/x86/kernel/acpi/wakeup_64.S @@ -5,6 +5,7 @@ #include #include #include +#include # Copyright 2003 Pavel Machek , distribute under GPLv2 @@ -39,6 +40,7 @@ bogus_64_magic: jmp bogus_64_magic ENTRY(do_suspend_lowlevel) + FRAME_BEGIN subq$8, %rsp xorl%eax, %eax callsave_processor_state @@ -109,6 +111,7 @@ ENTRY(do_suspend_lowlevel) xorl%eax, %eax addq$8, %rsp + FRAME_END jmp restore_processor_state ENDPROC(do_suspend_lowlevel) -- 2.4.3
[PATCH 14/33] x86/asm/crypto: Don't use rbp as a scratch register
The frame pointer (rbp) is getting clobbered in sha1_mb_mgr_submit_avx2() before a function call, which can mess up stack traces. Use r12 instead. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S b/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S index a5a14c62..c3b9447 100644 --- a/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S +++ b/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S @@ -86,8 +86,8 @@ job_rax = %rax len = %rax DWORD_len = %eax -lane= %rbp -tmp3= %rbp +lane= %r12 +tmp3= %r12 tmp = %r9 DWORD_tmp = %r9d @@ -99,7 +99,7 @@ lane_data = %r10 # arg 2 : rdx : job ENTRY(sha1_mb_mgr_submit_avx2) push%rbx - push%rbp + push%r12 mov _unused_lanes(state), unused_lanes mov unused_lanes, lane @@ -190,7 +190,7 @@ len_is_0: movlDWORD_tmp, _result_digest+1*16(job_rax) return: - pop %rbp + pop %r12 pop %rbx ret -- 2.4.3
[PATCH 13/33] x86/asm/crypto: Simplify stack usage in sha-mb functions
sha1_mb_mgr_flush_avx2() and sha1_mb_mgr_submit_avx2() both allocate a lot of stack space which is never used. Also, many of the registers being saved aren't being clobbered so there's no need to save them. Signed-off-by: Josh Poimboeuf --- arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 32 ++-- arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S | 29 +++-- 2 files changed, 6 insertions(+), 55 deletions(-) diff --git a/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S b/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S index 85c4e1c..672eaeb 100644 --- a/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S @@ -86,16 +86,6 @@ #define extra_blocks%arg2 #define p %arg2 - -# STACK_SPACE needs to be an odd multiple of 8 -_XMM_SAVE_SIZE = 10*16 -_GPR_SAVE_SIZE = 8*8 -_ALIGN_SIZE = 8 - -_XMM_SAVE = 0 -_GPR_SAVE = _XMM_SAVE + _XMM_SAVE_SIZE -STACK_SPACE = _GPR_SAVE + _GPR_SAVE_SIZE + _ALIGN_SIZE - .macro LABEL prefix n \prefix\n\(): .endm @@ -113,16 +103,7 @@ offset = \_offset # JOB* sha1_mb_mgr_flush_avx2(MB_MGR *state) # arg 1 : rcx : state ENTRY(sha1_mb_mgr_flush_avx2) - mov %rsp, %r10 - sub $STACK_SPACE, %rsp - and $~31, %rsp - mov %rbx, _GPR_SAVE(%rsp) - mov %r10, _GPR_SAVE+8*1(%rsp) #save rsp - mov %rbp, _GPR_SAVE+8*3(%rsp) - mov %r12, _GPR_SAVE+8*4(%rsp) - mov %r13, _GPR_SAVE+8*5(%rsp) - mov %r14, _GPR_SAVE+8*6(%rsp) - mov %r15, _GPR_SAVE+8*7(%rsp) + push%rbx # If bit (32+3) is set, then all lanes are empty mov _unused_lanes(state), unused_lanes @@ -230,16 +211,7 @@ len_is_0: mov tmp2_w, offset(job_rax) return: - - mov _GPR_SAVE(%rsp), %rbx - mov _GPR_SAVE+8*1(%rsp), %r10 #saved rsp - mov _GPR_SAVE+8*3(%rsp), %rbp - mov _GPR_SAVE+8*4(%rsp), %r12 - mov _GPR_SAVE+8*5(%rsp), %r13 - mov _GPR_SAVE+8*6(%rsp), %r14 - mov _GPR_SAVE+8*7(%rsp), %r15 - mov %r10, %rsp - + pop %rbx ret return_null: diff --git a/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S b/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S index 2ab9560..a5a14c62 100644 --- a/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S +++ b/arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S @@ -94,25 +94,12 @@ DWORD_tmp = %r9d lane_data = %r10 -# STACK_SPACE needs to be an odd multiple of 8 -STACK_SPACE = 8*8 + 16*10 + 8 - # JOB* submit_mb_mgr_submit_avx2(MB_MGR *state, job_sha1 *job) # arg 1 : rcx : state # arg 2 : rdx : job ENTRY(sha1_mb_mgr_submit_avx2) - - mov %rsp, %r10 - sub $STACK_SPACE, %rsp - and $~31, %rsp - - mov %rbx, (%rsp) - mov %r10, 8*2(%rsp) #save old rsp - mov %rbp, 8*3(%rsp) - mov %r12, 8*4(%rsp) - mov %r13, 8*5(%rsp) - mov %r14, 8*6(%rsp) - mov %r15, 8*7(%rsp) + push%rbx + push%rbp mov _unused_lanes(state), unused_lanes mov unused_lanes, lane @@ -203,16 +190,8 @@ len_is_0: movlDWORD_tmp, _result_digest+1*16(job_rax) return: - - mov (%rsp), %rbx - mov 8*2(%rsp), %r10 #save old rsp - mov 8*3(%rsp), %rbp - mov 8*4(%rsp), %r12 - mov 8*5(%rsp), %r13 - mov 8*6(%rsp), %r14 - mov 8*7(%rsp), %r15 - mov %r10, %rsp - + pop %rbp + pop %rbx ret return_null: -- 2.4.3
[PATCH 09/33] x86/paravirt: Create a stack frame in PV_CALLEE_SAVE_REGS_THUNK
A function created with the PV_CALLEE_SAVE_REGS_THUNK macro doesn't set
up a new stack frame before the call instruction, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace. Also, the thunk functions aren't annotated as ELF
callable functions.
Create a stack frame when CONFIG_FRAME_POINTER is enabled and add the
ELF function type.
Signed-off-by: Josh Poimboeuf
Reviewed-by: Borislav Petkov
Cc: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Alok Kataria
Cc: Rusty Russell
---
arch/x86/include/asm/paravirt.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index f619250..601f1b8 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
static inline int paravirt_enabled(void)
{
@@ -756,15 +757,19 @@ static __always_inline void __ticket_unlock_kick(struct
arch_spinlock *lock,
* call. The return value in rax/eax will not be saved, even for void
* functions.
*/
+#define PV_THUNK_NAME(func) "__raw_callee_save_" #func
#define PV_CALLEE_SAVE_REGS_THUNK(func)
\
extern typeof(func) __raw_callee_save_##func; \
\
asm(".pushsection .text;" \
- ".globl __raw_callee_save_" #func " ; " \
- "__raw_callee_save_" #func ": " \
+ ".globl " PV_THUNK_NAME(func) ";" \
+ ".type " PV_THUNK_NAME(func) ", @function;" \
+ PV_THUNK_NAME(func) ":" \
+ FRAME_BEGIN \
PV_SAVE_ALL_CALLER_REGS \
"call " #func ";" \
PV_RESTORE_ALL_CALLER_REGS \
+ FRAME_END \
"ret;" \
".popsection")
--
2.4.3
