Re: [PATCH 2/2] powercap/rapl: add support for denverton
On Tue, 31 May 2016, Dave Hansen wrote:
> On 05/31/2016 01:41 PM, Jacob Pan wrote:
> > --- a/drivers/powercap/intel_rapl.c
> > +++ b/drivers/powercap/intel_rapl.c
> > @@ -1137,6 +1137,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst
> > = {
> > RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights Landing */
> > RAPL_CPU(0x8E, rapl_defaults_core),/* Kabylake */
> > RAPL_CPU(0x9E, rapl_defaults_core),/* Kabylake */
> > + RAPL_CPU(0x5F, rapl_defaults_core),/* Denverton micro server */
> > {}
> > };
>
> Not to derail this individual patch... but do we really want to continue
> open-coding CPU model/family combos all over arch/x86?
>
> For instance, arch/x86/events/intel/core.c has:
>
> > case 142: /* 14nm Kabylake Mobile */
> > case 158: /* 14nm Kabylake Desktop */
> > case 78: /* 14nm Skylake Mobile */
> > case 94: /* 14nm Skylake Desktop */
> > case 85: /* 14nm Skylake Server */
>
> Which duplicates the two Kabylake family numbers from the RAPL_CPU()
> context above (just in decimal instead of hex).
>
> Should we just start sticking these things in a header like:
>
> #define X86_INTEL_FAMILY_KABYLAKE10x8E
> #define X86_INTEL_FAMILY_KABYLAKE20x9E
> #define X86_INTEL_FAMILY_DENVERTON0x5F
>
> So we have this:
>
> RAPL_CPU(X86_INTEL_FAMILY_DENVERTON, rapl_defaults_core),
>
> instead of having to explain our magic number in a comment.
Yes please.
Re: [PATCHv2] clocksource:fix kernel panic due late cs5535_clockevent
On Tue, 31 May 2016, Hans Ulli Kroll wrote:
> @@ -152,6 +153,9 @@ static int __init cs5535_mfgpt_init(void)
> }
> cs5535_event_clock = timer;
>
> + clockevents_config_and_register(&cs5535_clockevent, MFGPT_HZ,
> + 0xF, 0xFFFE);
> +
> /* Set up the IRQ on the MFGPT side */
> if (cs5535_mfgpt_setup_irq(timer, MFGPT_CMP2, &timer_irq)) {
> printk(KERN_ERR DRV_NAME ": Could not set up IRQ %d\n",
So what happens if that fails?
Thanks,
tglx
Re: [PATCH resend v2 5/6] ARM: dts: sun9i: a80-optimus: Disable dummy regulators vcc3v0, vcc3v3, vcc5v0
On Wed, Jun 01, 2016 at 10:45:51AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jun 1, 2016 at 3:01 AM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Wed, Jun 01, 2016 at 12:23:23AM +0800, Chen-Yu Tsai wrote:
> >> These 3 regulators are provided in sunxi-common-regulators.dtsi.
> >> 3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
> >> These dummy regulators provide a stand-in when bindings that require
> >> one, but the real regulator is not supported yet.
> >>
> >> Since these are no longer needed, we can disable them.
> >>
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >> arch/arm/boot/dts/sun9i-a80-optimus.dts | 12
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts
> >> b/arch/arm/boot/dts/sun9i-a80-optimus.dts
> >> index 6cfc02194035..991337d1d6f1 100644
> >> --- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
> >> +++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
> >> @@ -322,6 +322,18 @@
> >>
> >> #include "axp809.dtsi"
> >>
> >> +®_vcc3v0 {
> >> + status = "disabled";
> >> +};
> >> +
> >> +®_vcc3v3 {
> >> + status = "disabled";
> >> +};
> >> +
> >> +®_vcc5v0 {
> >> + status = "disabled";
> >> +};
> >> +
> >
> > Why not remove the include entirely?
>
> reg_usb1_vbus is still used. Or I could just copy it and
> get rid of the include.
Ah yes, it is on the Optimus (but not the cubieboard I initially
looked at).
Since we have that other regulator usb3 regulator, we can simply
remove it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 6/6] mm, oom: fortify task_will_free_mem
On Wed 01-06-16 00:29:33, Oleg Nesterov wrote:
> On 05/31, Michal Hocko wrote:
> >
> > On Mon 30-05-16 19:35:05, Oleg Nesterov wrote:
> > >
> > > Well, let me suggest this again. I think it should do
> > >
> > >
> > > if (SIGNAL_GROUP_COREDUMP)
> > > return false;
> > >
> > > if (SIGNAL_GROUP_EXIT)
> > > return true;
> > >
> > > if (thread_group_empty() && PF_EXITING)
> > > return true;
> > >
> > > return false;
> > >
> > > we do not need fatal_signal_pending(), in this case SIGNAL_GROUP_EXIT
> > > should
> > > be set (ignoring some bugs with sub-namespaces which we need to fix
> > > anyway).
> >
> > OK, so we shouldn't care about race when the fatal_signal is set on the
> > task until it reaches do_group_exit?
>
> if fatal_signal() is true then (ignoring exec and coredump) SIGNAL_GROUP_EXIT
> is already set (again, ignoring the bugs with sub-namespace inits).
>
> At the same time, SIGKILL can be already dequeued when the task exits, so
> fatal_signal_pending() can be "false negative".
Thanks for the clarification. I guess I got the point but this is a land
of surprises so one can never be sure...
> > > And. I think this needs smp_rmb() at the end of the loop (assuming we
> > > have the
> > > process_shares_mm() check here). We need it to ensure that we read p->mm
> > > before
> > > we read next_task(), to avoid the race with exit() + clone(CLONE_VM).
> >
> > Why don't we need the same barrier in oom_kill_process?
>
> Because it calls do_send_sig_info() which takes ->siglock and copy_process()
> takes the same lock. Not a barrier, but acts the same way.
Ahh ok, so an implicit barrier.
> > Which barrier it
> > would pair with?
>
> With the barrier implied by list_add_tail_rcu(&p->tasks, &init_task.tasks).
Ahh I see. rcu_assign_pointer that is, right?
> > Anyway I think this would deserve it's own patch.
> > Barriers are always tricky and it is better to have them in a small
> > patch with a full explanation.
>
> OK, agreed.
cool
> I am not sure I can read the new patch correctly, it depends on the previous
> changes... but afaics it looks good.
>
> Cosmetic/subjective nit, feel free to ignore,
>
> > +bool task_will_free_mem(struct task_struct *task)
> > +{
> > + struct mm_struct *mm = NULL;
>
> unnecessary initialization ;)
fixed
> > + struct task_struct *p;
> > + bool ret;
> > +
> > + /*
> > +* If the process has passed exit_mm we have to skip it because
> > +* we have lost a link to other tasks sharing this mm, we do not
> > +* have anything to reap and the task might then get stuck waiting
> > +* for parent as zombie and we do not want it to hold TIF_MEMDIE
> > +*/
> > + p = find_lock_task_mm(task);
> > + if (!p)
> > + return false;
> > +
> > + if (!__task_will_free_mem(p)) {
> > + task_unlock(p);
> > + return false;
> > + }
>
> We can call the 1st __task_will_free_mem(p) before find_lock_task_mm(). In the
> likely case (I think) it should return false.
OK
>
> And since __task_will_free_mem() has no other callers perhaps it should go
> into
> oom_kill.c too.
ok
I will resend the whole series with the fixups later during this week.
Thanks again for your review.
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] clocksource: Add Oxford Semiconductor RPS Dual Timer
On Tue, 31 May 2016, Neil Armstrong wrote:
> +static int oxnas_rps_timer_shutdown(struct clock_event_device *evt)
> +{
> + struct oxnas_rps_timer *rps =
> + container_of(evt, struct oxnas_rps_timer, clkevent);
> +
> + if (!clockevent_state_periodic(evt))
> + return 0;
So if the timer is in oneshot mode, then you just leave it enabled. What's the
rationale of this?
> +
> + oxnas_rps_timer_config(rps, 0, 0);
Thanks,
tglx
Re: [PATCH 4/6] mm, oom: skip vforked tasks from being selected
On Tue 31-05-16 23:43:38, Oleg Nesterov wrote:
> On 05/31, Michal Hocko wrote:
> >
> > On Mon 30-05-16 21:28:57, Oleg Nesterov wrote:
> > >
> > > I don't think we can trust vfork_done != NULL.
> > >
> > > copy_process() doesn't disallow CLONE_VFORK without CLONE_VM, so with
> > > this patch
> > > it would be trivial to make the exploit which hides a memory hog from
> > > oom-killer.
> >
> > OK, I wasn't aware of this possibility.
>
> Neither was me ;) I noticed this during this review.
Heh, as I've said in other email, this is a land of dragons^Wsurprises.
> > > Or I am totally confused?
> >
> > I cannot judge I am afraid. You are definitely much more familiar with
> > all these subtle details than me.
>
> OK, I just verified that clone(CLONE_VFORK|SIGCHLD) really works to be sure.
great, thanks
> > +/* expects to be called with task_lock held */
> > +static inline bool in_vfork(struct task_struct *tsk)
> > +{
> > + bool ret;
> > +
> > + /*
> > +* need RCU to access ->real_parent if CLONE_VM was used along with
> > +* CLONE_PARENT
> > +*/
> > + rcu_read_lock();
> > + ret = tsk->vfork_done && tsk->real_parent->mm == tsk->mm;
> > + rcu_read_unlock();
> > +
> > + return ret;
> > +}
>
> Yes, but may I ask to add a comment? And note that "expects to be called with
> task_lock held" looks misleading, we do not need the "stable" tsk->vfork_done
> since we only need to check if it is NULL or not.
OK, I thought it was needed for the stability but as you explain below
this is not really true...
> It would be nice to explain that
>
> 1. we check real_parent->mm == tsk->mm because CLONE_VFORK does not
> imply CLONE_VM
>
> 2. CLONE_VFORK can be used with CLONE_PARENT/CLONE_THREAD and thus
> ->real_parent is not necessarily the task doing vfork(), so in
> theory we can't rely on task_lock() if we want to dereference it.
>
> And in this case we can't trust the real_parent->mm == tsk->mm
> check, it can be false negative. But we do not care, if init or
> another oom-unkillable task does this it should blame itself.
I've stolen this explanation and put it right there.
--
Michal Hocko
SUSE Labs
Re: Internal error xfs_trans_cancel
On Wed, Jun 01, 2016 at 07:52:31AM +0200, Daniel Wagner wrote: > Hi, > > I got the error message below while compiling a kernel > on that system. I can't really say if I did something > which made the file system unhappy before the crash. > > > [Jun 1 07:41] XFS (sde1): Internal error xfs_trans_cancel at line 984 of file > fs/xfs/xfs_trans.c. Caller xfs_rename+0x453/0x960 [xfs] Anything in the log before this? > [ +0.95] CPU: 22 PID: 8640 Comm: gcc Not tainted 4.7.0-rc1 #16 > [ +0.35] Hardware name: Dell Inc. PowerEdge R820/066N7P, BIOS 2.0.20 > 01/16/2014 > [ +0.48] 0286 c8be6bc3 885fa9473cb0 > 813d146e > [ +0.56] 885fa9ac5ed0 0001 885fa9473cc8 > a0213cdc > [ +0.53] a02257b3 885fa9473cf0 a022eb36 > 883faa502d00 > [ +0.53] Call Trace: > [ +0.28] [] dump_stack+0x63/0x85 > [ +0.69] [] xfs_error_report+0x3c/0x40 [xfs] > [ +0.65] [] ? xfs_rename+0x453/0x960 [xfs] > [ +0.64] [] xfs_trans_cancel+0xb6/0xe0 [xfs] > [ +0.65] [] xfs_rename+0x453/0x960 [xfs] > [ +0.62] [] xfs_vn_rename+0xb3/0xf0 [xfs] > [ +0.40] [] vfs_rename+0x58c/0x8d0 > [ +0.32] [] SyS_rename+0x371/0x390 > [ +0.36] [] entry_SYSCALL_64_fastpath+0x1a/0xa4 > [ +0.40] XFS (sde1): xfs_do_force_shutdown(0x8) called from line 985 of > file fs/xfs/xfs_trans.c. Return address = 0xa022eb4f > [ +0.027680] XFS (sde1): Corruption of in-memory data detected. Shutting > down filesystem > [ +0.57] XFS (sde1): Please umount the filesystem and rectify the > problem(s) > [Jun 1 07:42] XFS (sde1): xfs_log_force: error -5 returned. > [ +30.081016] XFS (sde1): xfs_log_force: error -5 returned. Doesn't normally happen, and there's not a lot to go on here. Can you provide the info listed in the link below so we have some idea of what configuration the error occurred on? http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F You didn't run out of space or something unusual like that? Does 'xfs_repair -n ' report any errors? Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH] Bluetooth: btmrvl_main: read wakeup-pin and gpio_gap as u32
The dt binding document for Marvell bt-sd8897 specify the
'marvell,wakeup-pin' and 'marvell,gpio-gap-ms' attributes to be a 32-bit
value, but the driver parse it as 16-bit instead. Fix this to meet the
dt-binding document, and to be consistent with the 'marvell,wakeup-pin'
property in the mwifiex driver.
Signed-off-by: Wei-Ning Huang
---
drivers/bluetooth/btmrvl_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 7ad8d61..b6d3404 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -513,21 +513,21 @@ static int btmrvl_check_device_tree(struct btmrvl_private
*priv)
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
u8 cal_data[BT_CAL_HDR_LEN + BT_CAL_DATA_SIZE];
int ret = 0;
- u16 gpio, gap;
+ u32 gpio, gap;
if (card->plt_of_node) {
dt_node = card->plt_of_node;
- ret = of_property_read_u16(dt_node, "marvell,wakeup-pin",
+ ret = of_property_read_u32(dt_node, "marvell,wakeup-pin",
&gpio);
if (ret)
gpio = (priv->btmrvl_dev.gpio_gap & 0xff00) >> 8;
- ret = of_property_read_u16(dt_node, "marvell,wakeup-gap-ms",
+ ret = of_property_read_u32(dt_node, "marvell,wakeup-gap-ms",
&gap);
if (ret)
gap = (u8)(priv->btmrvl_dev.gpio_gap & 0x00ff);
- priv->btmrvl_dev.gpio_gap = (gpio << 8) + gap;
+ priv->btmrvl_dev.gpio_gap = ((gpio & 0xff) << 8) + (gap & 0xff);
ret = of_property_read_u8_array(dt_node, "marvell,cal-data",
cal_data + BT_CAL_HDR_LEN,
--
2.1.2
[PATCH v10 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation
Device-tree binding documentation for Xilinx zynqmp dma engine
used in Zynq UltraScale+ MPSoC.
Acked-by: Rob Herring
Signed-off-by: Punnaiah Choudary Kalluri
Signed-off-by: Kedareswara rao Appana
---
Changes in v10:
- Added Rob Acked-by in the commit message.
Changs in v9:
- Removed include sg runtime configuration parameter
from the binding doc as suggested by Lars.
Changes in v8:
- Removed all the software runtime configuration parameters
from the binding doc as suggested by the Lars.
Changes in v7:
- None.
Changes in v6:
- Removed desc-axi-cache/dst-axi-cache/src-axi-cache properties
from the binding doc as it allow broken combinations when dma-coherent
is set as suggested by Rob.
- Fixed minor comments given by Rob related coding(lower case DT node name).
Changes in v5:
- Use dma-coherent flag for coherent transfers as suggested by rob.
- Removed unnecessary properties from binding doc as suggested by Rob.
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None.
.../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..a784cdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,27 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible : Should be "xlnx,zynqmp-dma-1.0"
+- reg : Memory map for gdma/adma module access.
+- interrupt-parent : Interrupt controller the interrupt is routed through
+- interrupts : Should contain DMA channel interrupt.
+- xlnx,bus-width : Axi buswidth in bits. Should contain 128 or 64
+- clock-names : List of input clocks "clk_main", "clk_apb"
+ (see clock bindings for details)
+
+Optional properties:
+- dma-coherent : Present if dma operations are coherent.
+
+Example:
+
+fpd_dma_chan1: dma@fd50 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x0 0xFD50 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 117 4>;
+ clock-names = "clk_main", "clk_apb";
+ xlnx,bus-width = <128>;
+ dma-coherent;
+};
--
2.1.2
[PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
Added the driver for zynqmp dma engine used in Zynq
UltraScale+ MPSoC. This dma controller supports memory to memory
and memory to I/O buffer transfers.
Signed-off-by: Punnaiah Choudary Kalluri
Signed-off-by: Kedareswara rao Appana
---
Changes for v10:
- Use 64bit write for 64-bit platforms as suggested by Shubhrajyoti.
Changes for v9:
- Derive the include sg software runtime configuration parameter
through config strucutre as suggested by the Lars.
Changes for v8:
- Derive the software runtime configuration parameters
through config strucutre and configure them during transfer
as suggested by the Lars.
Changes for v7:
- Fixed kbuild compilation warnings.
- Fixed {src,dst}_addr_widths are supposed to be a bitmask of
supported slave device widths as suggested by Rob.
Changes in v6:
- Removed unnecessary axcache properties from the driver
- Fixed compilation issues
Changes in v5:
- Removed in_interrupt check from the tasklet cleanup as
suggested by the vinod/lars.
Changes in v4:
- Modified the defines to start with ZYNQMP_DMA perfix
- Changed the zynqmp_dma_alloc_chan_resources to return number of
allocated descriptors
- Changed the zynqmp_dma_device variable name
- Released the locks before calling user callback
- freeup irq in zynqmp_dma_chan_remove function.
Changes in v3:
- Modified the zynqmp_dma_chan_is_idle function return type to bool
Changes in v2:
- Corrected the function header documentation
- Framework expects bus-width value in bytes. so, fixed it
- Removed magic numbers for bus-width
drivers/dma/Kconfig |6 +
drivers/dma/xilinx/Makefile |1 +
drivers/dma/xilinx/zynqmp_dma.c | 1269 +++
3 files changed, 1276 insertions(+)
create mode 100644 drivers/dma/xilinx/zynqmp_dma.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 8c98779..629e339 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -541,6 +541,12 @@ config ZX_DMA
help
Support the DMA engine for ZTE ZX296702 platform devices.
+config XILINX_ZYNQMP_DMA
+ tristate "Xilinx ZynqMP DMA Engine"
+ depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
+ select DMA_ENGINE
+ help
+ Enable support for Xilinx ZynqMP DMA controller.
# driver files
source "drivers/dma/bestcomm/Kconfig"
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..95469dc 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
new file mode 100644
index 000..dd05eff
--- /dev/null
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -0,0 +1,1269 @@
+/*
+ * DMA driver for Xilinx ZynqMP DMA Engine
+ *
+ * Copyright (C) 2016 Xilinx, Inc. All rights reserved.
+ *
+ * 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
+#include
+
+#include "../dmaengine.h"
+
+/* Register Offsets */
+#define ZYNQMP_DMA_ISR 0x100
+#define ZYNQMP_DMA_IMR 0x104
+#define ZYNQMP_DMA_IER 0x108
+#define ZYNQMP_DMA_IDS 0x10C
+#define ZYNQMP_DMA_CTRL0 0x110
+#define ZYNQMP_DMA_CTRL1 0x114
+#define ZYNQMP_DMA_DATA_ATTR 0x120
+#define ZYNQMP_DMA_DSCR_ATTR 0x124
+#define ZYNQMP_DMA_SRC_DSCR_WRD0 0x128
+#define ZYNQMP_DMA_SRC_DSCR_WRD1 0x12C
+#define ZYNQMP_DMA_SRC_DSCR_WRD2 0x130
+#define ZYNQMP_DMA_SRC_DSCR_WRD3 0x134
+#define ZYNQMP_DMA_DST_DSCR_WRD0 0x138
+#define ZYNQMP_DMA_DST_DSCR_WRD1 0x13C
+#define ZYNQMP_DMA_DST_DSCR_WRD2 0x140
+#define ZYNQMP_DMA_DST_DSCR_WRD3 0x144
+#define ZYNQMP_DMA_SRC_START_LSB 0x158
+#define ZYNQMP_DMA_SRC_START_MSB 0x15C
+#define ZYNQMP_DMA_DST_START_LSB 0x160
+#define ZYNQMP_DMA_DST_START_MSB 0x164
+#define ZYNQMP_DMA_RATE_CTRL 0x18C
+#define ZYNQMP_DMA_IRQ_SRC_ACCT0x190
+#define ZYNQMP_DMA_IRQ_DST_ACCT0x194
+#define ZYNQMP_DMA_CTRL2 0x200
+
+/* Interrupt registers bit field definitions */
+#define ZYNQMP_DMA_DONEBIT(10)
+#define ZYNQMP_DMA_AXI_WR_DATA BIT(9)
+#define ZYNQMP_DMA_AXI_RD_DATA BIT(8)
+#define ZYNQMP_DMA_AXI_RD_DST_DSCR BIT(7)
+#define ZYNQMP_DMA_AXI_RD_SRC_DSCR BIT(6)
+#define ZYNQMP_DMA_IRQ_DST_ACCT_ERRBIT(5)
+#define ZYNQMP_DMA_IRQ_SRC_ACCT_ERRBIT(4)
+#define ZYNQMP_DMA_BYTE_CNT_OVRFL BIT(3)
+#define ZYNQMP_DMA_DST_DSCR_DONE B
Re: [PATCH] dt: bindings: fix documentation for MARVELL's bt-sd8xxx wireless device
Please ignore this patch. I think we should make the driver parse 32 bit value instead (to be consistent with mwifiex driver). On Wed, Jun 1, 2016 at 11:09 AM, Wei-Ning Huang wrote: > The property marvell,wakeup-pin and marvell,wakeup-gap-ms are read as > u16 in the driver. Fix documentation and example accordingly. > > Signed-off-by: Wei-Ning Huang > --- > Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt > b/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt > index 14aa6cf..6a9a63c 100644 > --- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt > +++ b/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt > @@ -13,10 +13,10 @@ Optional properties: > initialization. This is an array of 28 values(u8). > >- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth > chip. > - firmware will use the pin to wakeup host system. > + firmware will use the pin to wakeup host system (u16). >- marvell,wakeup-gap-ms: wakeup gap represents wakeup latency of the host > platform. The value will be configured to firmware. This > - is needed to work chip's sleep feature as expected. > + is needed to work chip's sleep feature as expected > (u16). >- interrupt-parent: phandle of the parent interrupt controller >- interrupts : interrupt pin number to the cpu. Driver will request an irq > based > on this interrupt number. During system suspend, the irq > will be > @@ -50,7 +50,7 @@ calibration data is also available in below example. > 0x37 0x01 0x1c 0x00 0xff 0xff 0xff 0xff 0x01 0x7f > 0x04 0x02 > 0x00 0x00 0xba 0xce 0xc0 0xc6 0x2d 0x00 0x00 0x00 > 0x00 0x00 > 0x00 0x00 0xf0 0x00>; > - marvell,wakeup-pin = <0x0d>; > - marvell,wakeup-gap-ms = <0x64>; > + marvell,wakeup-pin = /bits/ 16 <0x0d>; > + marvell,wakeup-gap-ms = /bits/ 16 <0x64>; > }; > }; > -- > 2.1.2 > -- Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan | wnhu...@google.com | Cell: +886 910-380678
[PATCH v2] Bluetooth: btmrvl_main: read wakeup-pin and wakeup-gap-ms as u32
The dt binding document for Marvell bt-sd8897 specify the
'marvell,wakeup-pin' and 'marvell,wakeup-gap-ms' attributes to be a 32-bit
value, but the driver parse it as 16-bit instead. Fix this to meet the
dt-binding document, and to be consistent with the 'marvell,wakeup-pin'
property in the mwifiex driver.
Signed-off-by: Wei-Ning Huang
---
drivers/bluetooth/btmrvl_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 7ad8d61..b6d3404 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -513,21 +513,21 @@ static int btmrvl_check_device_tree(struct btmrvl_private
*priv)
struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
u8 cal_data[BT_CAL_HDR_LEN + BT_CAL_DATA_SIZE];
int ret = 0;
- u16 gpio, gap;
+ u32 gpio, gap;
if (card->plt_of_node) {
dt_node = card->plt_of_node;
- ret = of_property_read_u16(dt_node, "marvell,wakeup-pin",
+ ret = of_property_read_u32(dt_node, "marvell,wakeup-pin",
&gpio);
if (ret)
gpio = (priv->btmrvl_dev.gpio_gap & 0xff00) >> 8;
- ret = of_property_read_u16(dt_node, "marvell,wakeup-gap-ms",
+ ret = of_property_read_u32(dt_node, "marvell,wakeup-gap-ms",
&gap);
if (ret)
gap = (u8)(priv->btmrvl_dev.gpio_gap & 0x00ff);
- priv->btmrvl_dev.gpio_gap = (gpio << 8) + gap;
+ priv->btmrvl_dev.gpio_gap = ((gpio & 0xff) << 8) + (gap & 0xff);
ret = of_property_read_u8_array(dt_node, "marvell,cal-data",
cal_data + BT_CAL_HDR_LEN,
--
2.1.2
[PATCH v2 1/2] usb: misc: usb3503: Set platform data
Driver supports two paths of device instantiation: as platform and i2c device. In the platform path it lacks of storing the driver specific structure as drvdata. Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. New patch. --- drivers/usb/misc/usb3503.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c index b45cb77c0744..0cf2987b322f 100644 --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -338,6 +338,7 @@ static int usb3503_platform_probe(struct platform_device *pdev) if (!hub) return -ENOMEM; hub->dev = &pdev->dev; + platform_set_drvdata(pdev, hub); return usb3503_probe(hub); } -- 1.9.1
[PATCH v2 2/2] usb: misc: usb3503: Clean up on driver unbind
The driver should clean up after itself by unpreparing the clock when it
is unbound.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
Changes since v1:
1. Add Javier's tag.
2. Follow Javier's suggestion - the 'hub' cannot be null now.
---
drivers/usb/misc/usb3503.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 0cf2987b322f..8e7737d7ac0a 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -330,6 +330,17 @@ static int usb3503_i2c_probe(struct i2c_client *i2c,
return usb3503_probe(hub);
}
+static int usb3503_i2c_remove(struct i2c_client *i2c)
+{
+ struct usb3503 *hub;
+
+ hub = i2c_get_clientdata(i2c);
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ return 0;
+}
+
static int usb3503_platform_probe(struct platform_device *pdev)
{
struct usb3503 *hub;
@@ -343,6 +354,17 @@ static int usb3503_platform_probe(struct platform_device
*pdev)
return usb3503_probe(hub);
}
+static int usb3503_platform_remove(struct platform_device *pdev)
+{
+ struct usb3503 *hub;
+
+ hub = platform_get_drvdata(pdev);
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ return 0;
+}
+
#ifdef CONFIG_PM_SLEEP
static int usb3503_i2c_suspend(struct device *dev)
{
@@ -396,6 +418,7 @@ static struct i2c_driver usb3503_i2c_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_i2c_probe,
+ .remove = usb3503_i2c_remove,
.id_table = usb3503_id,
};
@@ -405,6 +428,7 @@ static struct platform_driver usb3503_platform_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_platform_probe,
+ .remove = usb3503_platform_remove,
};
static int __init usb3503_init(void)
--
1.9.1
[GIT PULL] pin control fixes for v4.7, take one
Hi Linus, here are three pin control fixes for v4.7. Not much, and just driver fixes. Please pull them in! Yours, Linus Walleij The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v4.7-2 for you to fetch changes up to 5edf673d07fdcb6498be24914f3f38f8d8843199: pinctrl: mediatek: fix dual-edge code defect (2016-05-31 10:13:45 +0200) Pin control fixes for v4.7: - Add device tree matches to MAINTAINERS - Inversion bug in the Nomadik driver - Dual edge handling bug in the mediatek driver Geert Uytterhoeven (1): MAINTAINERS: Add file patterns for pinctrl device tree bindings Linus Walleij (1): pinctrl: nomadik: fix inversion of gpio direction hongkun.cao (1): pinctrl: mediatek: fix dual-edge code defect MAINTAINERS | 1 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 5 +++-- drivers/pinctrl/nomadik/pinctrl-nomadik.c | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-)
RE: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller
Hi all
In v7 thread Lorenzo has summarized a roadmap to
get ACPI support for PCI controllers upstream.
The second point of the roadmap was
<< 2) In a real world (1) is not enough. Some ARM64 platforms, not entirely
ECAM compliant, already shipped with the corresponding firmware that
we can't update. HW has ECAM quirks and to work around it in the kernel
we put forward many solutions to the problem, it is time we found a
solution (when, of course, (1) is completed and upstream).
Using the MCFG table OEMID matching floated around in this thread
would work fine for most of the platforms (and cross-OS) that have
shipped with HW ECAM quirks, so I think that's the starting point for
our solution and that's how we can sort this out, _today_.
The solution is a trivial look-up table:
MCFG OEMID <-> PCI config space ops >>
I think maybe it is worth to post this quirk mechanism as RFC on
top of this v8 patchset, so that we can start to review it and
make some progress on the quirks.
If you agree I think Jon can tell who's the best person to
push the quirk RFC (as my understanding is that this mechanism
is currently used by some platforms deployed on the market...)
Thanks
Gab
> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 30 May 2016 16:14
> To: helg...@kernel.org; a...@arndb.de; will.dea...@arm.com;
> catalin.mari...@arm.com; raf...@kernel.org; hanjun@linaro.org;
> lorenzo.pieral...@arm.com; ok...@codeaurora.org; jchan...@broadcom.com
> Cc: robert.rich...@caviumnetworks.com; m...@semihalf.com;
> liviu.du...@arm.com; dda...@caviumnetworks.com; Wangyijing;
> suravee.suthikulpa...@amd.com; msal...@redhat.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> a...@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> a...@lists.linaro.org; j...@redhat.com; andrea.ga...@linaro.org;
> dhd...@apm.com; jeremy.lin...@arm.com; liudongdong (C);
> c...@codeaurora.org; Tomasz Nowicki
> Subject: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host
> controller
>
> From the functionality point of view this series may be split into the
> following logic parts:
> 1. Export ECAM API and add parent device to pci_config_window
> 2. Add IO resources handling to PCI core code
> 3. Support for generic domain assignment based on ACPI
> 4. New MCFG driver
> 5. Implement ARM64 ACPI based PCI host controller driver under
> arch/arm64/
>
> Patches has been built on top of 4.7-rc1 and can be found here:
> g...@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v8)
>
> This has been tested on Cavium ThunderX server. Any help in reviewing
> and
> testing is very appreciated.
>
> v7 -> v8
> - move code from drivers/acpi/pci_root_generic.c to
> arch/arm64/kernel/pci.c
> - minor changes around domain assignment
> - pci_mcfg.c improvements for parsing MCFG tables and lookup its
> entries
>
> v6 -> v7
> - drop quirks handling
> - changes for ACPI companion and domain number assignment approach
> - implement arch pcibios_{add|remove}_bus and call
> acpi_pci_{add|remove}_bus from there
> - cleanups around nomenclature
> - use resources oriented API for ECAM
> - fix for based address calculation before mapping ECAM region
> - remove useless lock for MCFG lookup
> - move MCFG stuff to separated file pci_mcfg.c
> - drop MCFG entries caching
> - rebase against 4.6-rc7
>
> v5 -> v6
> - drop idea of x86 MMCONFIG code refactoring
> - integrate JC's patches which introduce new ECAM API:
> https://lkml.org/lkml/2016/4/11/907
> git: https://github.com/jchandra-brcm/linux/ (arm64-acpi-pci-v3)
> - integrate Sinan's fix for releasing IO resources, see patch [06/13]
> - added ACPI support for ThunderX ECAM and PEM drivers
> - rebase against 4.6-rc2
>
> v4 -> v5
> - drop MCFG refactoring group patches 1-6 from series v4 and integrate
> Jayachandran's patch
> https://patchwork.ozlabs.org/patch/575525/
> - rewrite PCI legacy IRQs allocation
> - squash two patches 11 and 12 from series v4, fixed bisection issue
> - changelog improvements
> - rebase against 4.5-rc3
>
> v3 -> v4
> - drop Jiang's fix
> http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04318.html
> - add Lorenzo's fix patch 19/24
> - ACPI PCI bus domain number assigning cleanup
> - change resource management, we now claim and reassign resources
> - improvements for applying quirks
> - drop Matthew's http://www.spinics.net/lists/linux-pci/msg45950.html
> dependency
> - rebase against 4.5-rc1
>
> v2 -> v3
> - fix legacy IRQ assigning and IO ports registration
> - remove reference to arch specific companion device for ia64
> - move ACPI PCI host controller driver to pci_root.c
> - drop generic domain assignment for x86 and ia64 as I am not
> able to run all necessary test variants
> - drop patch which cleaned legacy IRQ assignment since it belongs to
> Mathew's series:
> https://patchw
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
> @@ -530,6 +683,8 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
> }
> mutex_unlock(&udc_lock);
>
> + mutex_unlock(&udc_lock);
> +
Here, you have one more mutex_unlock.
Peter
> kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> flush_work(&gadget->work);
> device_unregister(&udc->dev);
> @@ -539,6 +694,13 @@ EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>
> /* -
> */
>
> +struct otg_gadget_ops otg_gadget_intf = {
> + .start = usb_gadget_start,
> + .stop = usb_gadget_stop,
> + .connect_control = usb_gadget_connect_control,
> +};
> +
> +/* udc_lock must be held */
> static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver
> *driver)
> {
> int ret;
> @@ -553,12 +715,20 @@ static int udc_bind_to_driver(struct usb_udc *udc,
> struct usb_gadget_driver *dri
> ret = driver->bind(udc->gadget, driver);
> if (ret)
> goto err1;
> - ret = usb_gadget_udc_start(udc);
> - if (ret) {
> - driver->unbind(udc->gadget);
> - goto err1;
> +
> + /* If OTG, the otg core starts the UDC when needed */
> + if (udc->gadget->otg_dev) {
> + mutex_unlock(&udc_lock);
> + usb_otg_register_gadget(udc->gadget, &otg_gadget_intf);
> + mutex_lock(&udc_lock);
> + } else {
> + ret = usb_gadget_udc_start(udc);
> + if (ret) {
> + driver->unbind(udc->gadget);
> + goto err1;
> + }
> + usb_udc_connect_control(udc);
> }
> - usb_udc_connect_control(udc);
>
> kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
> return 0;
> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
> return -EOPNOTSUPP;
> }
>
> + /* In OTG mode we don't support softconnect, but b_bus_req */
> + if (udc->gadget->otg_dev) {
> + dev_err(dev, "soft-connect not supported in OTG mode\n");
> + return -EOPNOTSUPP;
> + }
> +
> if (sysfs_streq(buf, "connect")) {
> usb_gadget_udc_start(udc);
> - usb_gadget_connect(udc->gadget);
> + usb_udc_connect_control(udc);
> } else if (sysfs_streq(buf, "disconnect")) {
> usb_gadget_disconnect(udc->gadget);
> udc->driver->disconnect(udc->gadget);
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 3ecfddd..79d654f 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -1162,6 +1162,10 @@ extern int usb_add_gadget_udc(struct device *parent,
> struct usb_gadget *gadget);
> extern void usb_del_gadget_udc(struct usb_gadget *gadget);
> extern char *usb_get_gadget_udc_name(void);
>
> +extern int usb_otg_add_gadget_udc(struct device *parent,
> + struct usb_gadget *gadget,
> + struct device *otg_dev);
> +
> /*-*/
>
> /* utility to simplify dealing with string descriptors */
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
[PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
Implementations might use different IRQs for
host, gadget and OTG so use named interrupt resources
to allow Device tree to specify the 3 interrupts.
Following are the interrupt names
Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interrupt - otg
We still maintain backward compatibility for a single named
interrupt for all 3 interrupts (e.g. for dwc3-pci) and
single unnamed interrupt for all 3 interrupts (e.g. old DT).
Signed-off-by: Roger Quadros
---
v9: rebased on top of balbi/testing/next
drivers/usb/dwc3/core.c | 10 --
drivers/usb/dwc3/gadget.c | 20 ++--
drivers/usb/dwc3/host.c | 19 +++
3 files changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9c4e1d8d..5cedf3d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "missing IRQ\n");
- return -ENODEV;
- }
- dwc->xhci_resources[1].start = res->start;
- dwc->xhci_resources[1].end = res->end;
- dwc->xhci_resources[1].flags = res->flags;
- dwc->xhci_resources[1].name = res->name;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c37168d..c18c72f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
int ret = 0;
int irq;
- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
+ irq = dwc->irq_gadget;
ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
IRQF_SHARED, "dwc3", dwc->ev_buf);
if (ret) {
@@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
irq, ret);
goto err0;
}
- dwc->irq_gadget = irq;
spin_lock_irqsave(&dwc->lock, flags);
if (dwc->gadget_driver) {
@@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
int dwc3_gadget_init(struct dwc3 *dwc)
{
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
+
+ dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
+ if (dwc->irq_gadget <= 0) {
+ dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
+ "dwc_usb3");
+ if (dwc->irq_gadget <= 0) {
+ res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
+ 0);
+ if (!res) {
+ dev_err(dwc->dev, "missing peripheral IRQ\n");
+ return -ENODEV;
+ }
+ dwc->irq_gadget = res->start;
+ }
+ }
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
&dwc->ctrl_req_addr, GFP_KERNEL);
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..f2b60a4 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
struct platform_device *xhci;
struct usb_xhci_pdata pdata;
int ret;
+ struct resource *res;
+ struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
+
+ res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ, "host");
+ if (!res) {
+ res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
+ "dwc_usb3");
+ if (!res) {
+ res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
+ 0);
+ if (!res)
+ return -ENOMEM;
+ }
+ }
+
+ dwc->xhci_resources[1].start = res->start;
+ dwc->xhci_resources[1].end = res->end;
+ dwc->xhci_resources[1].flags = res->flags;
+ dwc->xhci_resources[1].name = res->name;
xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
if (!xhci) {
--
2.7.4
Re: [PATCH v2 4/8] zram: use crypto api to check alg availability
On (06/01/16 15:47), Minchan Kim wrote: [..] > > so both BUILTIN and BUILT-AS-A-MODULE cases are handled at compile > > time now and we can avoid crypto_has_comp() checks for most of the > > comp_algorithm calls, except for the case when someone requests an > > out-of-tree module. > > Hmm, isn't it problem, either? > > That module was built but not installed. In that case, setting the > algorithm will be failed. IOW, we are lying to user. have you ever seen this? really, why should we even bother? if there is no requested algorithm we will fallback to LZO. and how is that different from: user enabled LZO in .config (because it's a prerequisite for zram) but forgot to install the module? do we have to "fix" this as well?... implement our own LZO compression in zram? or `cp lib/lzo/* drivers/block/zram/'? > For solving the problem, if we check it with crypto_has_comp, again, > it will load module into memory. :( this will require a *VERY* non-standard behaviour from user cat /sys/block/zram0/comp_algorithm [lzo] lz4 # um... echo 842 > /sys/block/zram0/comp_algorithm and I'm quite confident that anyone who does this actually want to init the device with the requested out-of-tree module right after `echo FOO > comp_algorithm', rather than anything else. -ss
Re: [PATCH] ARM: uniphier: drop code for old DT binding
On Wednesday, June 1, 2016 3:30:03 PM CEST Masahiro Yamada wrote:
> Hi Arnd.
>
> 2016-05-31 18:21 GMT+09:00 Arnd Bergmann :
> > On Tuesday, May 31, 2016 5:17:08 PM CEST Masahiro Yamada wrote:
> >> Commit 307d40c56b0c ("ARM: uniphier: rework SMP code to support new
> >> System Bus binding") added a new DT binding for SMP code, but still
> >> kept old code for the backward compatibility.
> >>
> >> Linux 4.6 was out with both bindings supported, so it should not
> >> hurt to drop the old code now.
> >>
> >> Signed-off-by: Masahiro Yamada
> >>
> >
> > That explanation is in general not sufficient. Are you sure that
> > nobody is shipping a machine with their own dts file that is not
> > merged upstream, and that there are no bootloaders that have a
> > hardcoded dtb file that we need to support indefinitely?
> >
>
> I have to confess that almost no one (except me) uses this upstreamed
> code directly.
> It can boot, but it is almost useless for practical uses (at least for
> production level)
> because it still lacks lots of drivers.
>
> Our products based on ARM 32bit SoCs were shipped with old kernel
> (without device tree) that were never upstreamed.
That's fine, a lot of companies work like this when the upstreaming
starts, just mention this in the changelog.
> Socionext is now trying to change the development procedure
> and the situation will be much better for ARM64 SoC products; it will be
> more community-based development, although they are not shipped yet.
>
> So, the answer is, nobody is shipping ARM32 products using this upstream
> code.
> Device Tree is not used in the first place.
> (But, I still believe I should keep upstreaming.)
Ok.
Arnd
RE: [PATCH v2 3/3] ACPI / button: Send "open" state after boot/resume
Hi, [cut] > > We could have a parameter (say "send_lid_open_on_resume" or > > "use_bios_lid_value") in acpi/button.c which would allow people to > > choose if they want the "new" behavior or the old one. And we could > > also add some DMI matching for the messed up laptops/tablets where > we > > force one or the other quirk. When we agree that user space now > > behaves gently with us, we could then remove entirely the quirk and > > the dmi matching. > > > > How does that sound? > [Lv Zheng] > The choices are in my first revision. > I could restore it back and re-send this series. > Also I need to update PATCH 02 to eliminate wrong IS_ERR_VALUE(). [Lv Zheng] I forgot to mention. IMO, if the issue is because of uncertain gaps, not a confirmed BIOS bug, or a confirmed gap that has to be solved in a spirit of compromise, we should not add quirks. We could just provide boot parameters for users to choose. Because the quirk table could grow bigger and bigger, exceeding our control. So I probably would just implement the parameter part, without adding the DMI entries. Thanks and best regards -Lv
Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs
On Wed, Jun 01, 2016 at 07:36:42AM +0200, Krzysztof Kozlowski wrote: > > No really for this patch, but I would much prefer to document them next > > to the code in the long run. Also I really think these BIT() macros > > are a distraction compared to the (1 << N) notation. > > Not much difference to me but maybe plain number: > ... 0x01u > ... 0x02u > ? I prefer the little bit shifts, but even the explicit values are much better than the obsfucating macros :) Anyway, your patch and in the end all three methods will get the work done. > > I'd just kill this helper, much easier to simply open code it in the > > caller. > > Keeping it for now helps reducing the number of changes in the patch. > The patch will be quite big as it has to replace all the uses atomically. > > I can get rid of the helper in consecutive patch. Sounds fine.
[PATCH v2] phy: ti-pipe3: Program the DPLL even if it was already locked
If bootloader has set a wrong DPLL then we must trash those values
and re-program it anyways. This fixes USB3 devices not being enumerated
on Beagleboard-x15 if usb was started in u-boot. (e.g. v2016.05)
We don't re-program SATA DPLL if it is locked as it was causing
SATA failures if device was hotpluged after boot. This might be due
to i818 "SATA PHY Reset Required Following SATA PLL Unlock".
Signed-off-by: Roger Quadros
---
v2:
- updated commit message. fixed board name and added SATA DPLL errata details.
drivers/phy/phy-ti-pipe3.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0a477d2..bf46844 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -293,11 +293,18 @@ static int ti_pipe3_init(struct phy *x)
ret = ti_pipe3_dpll_wait_lock(phy);
}
- /* Program the DPLL only if not locked */
+ /* SATA has issues if re-programmed when locked */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
- if (!(val & PLL_LOCK))
- if (ti_pipe3_dpll_program(phy))
- return -EINVAL;
+ if ((val & PLL_LOCK) && of_device_is_compatible(phy->dev->of_node,
+ "ti,phy-pipe3-sata"))
+ return ret;
+
+ /* Program the DPLL */
+ ret = ti_pipe3_dpll_program(phy);
+ if (ret) {
+ ti_pipe3_disable_clocks(phy);
+ return -EINVAL;
+ }
return ret;
}
--
2.7.4
[PATCH 1/4] inotify: Add infrastructure to account inotify limits per-namespace
This patch adds the necessary members to user_struct. The idea behind
the solution is really simple - user the userns pointers as keys into
a hash table which holds the inotify instances/watches counts. This
allows to account the limits per userns rather than per real user,
which makes certain scenarios such as a single mapped user in a
container deplete the inotify resources for all other users, which
map to the exact same real user.
Signed-off-by: Nikolay Borisov
---
fs/notify/inotify/inotify.h | 68
fs/notify/inotify/inotify_user.c | 36 +
include/linux/fsnotify_backend.h | 1 +
include/linux/sched.h| 3 ++
kernel/user.c| 13
5 files changed, 121 insertions(+)
diff --git a/fs/notify/inotify/inotify.h b/fs/notify/inotify/inotify.h
index ed855ef6f077..e069e1e4262a 100644
--- a/fs/notify/inotify/inotify.h
+++ b/fs/notify/inotify/inotify.h
@@ -1,6 +1,7 @@
#include
#include
#include /* struct kmem_cache */
+#include
struct inotify_event_info {
struct fsnotify_event fse;
@@ -15,6 +16,13 @@ struct inotify_inode_mark {
int wd;
};
+struct inotify_state {
+ struct hlist_node node;
+ void *key; /* user_namespace ptr */
+ u32 inotify_watches; /* How many inotify watches does this user have? */
+ u32 inotify_devs; /* How many inotify devs does this user have opened?
*/
+};
+
static inline struct inotify_event_info *INOTIFY_E(struct fsnotify_event *fse)
{
return container_of(fse, struct inotify_event_info, fse);
@@ -30,3 +38,63 @@ extern int inotify_handle_event(struct fsnotify_group *group,
const unsigned char *file_name, u32 cookie);
extern const struct fsnotify_ops inotify_fsnotify_ops;
+
+/* Helpers for manipulating various inotify state, stored in user_struct */
+static inline struct inotify_state *__find_inotify_state(struct user_struct
*user,
+ void *key)
+{
+ struct inotify_state *state;
+
+ hash_for_each_possible(user->inotify_tbl, state, node, (unsigned
long)key)
+ if (state->key == key)
+ return state;
+
+ return NULL;
+}
+
+static inline void inotify_inc_watches(struct user_struct *user, void *key)
+{
+ struct inotify_state *state;
+
+ spin_lock(&user->inotify_lock);
+ state = __find_inotify_state(user, key);
+ state->inotify_watches++;
+ spin_unlock(&user->inotify_lock);
+}
+
+
+static inline void inotify_dec_watches(struct user_struct *user, void *key)
+{
+ struct inotify_state *state;
+
+ spin_lock(&user->inotify_lock);
+ state = __find_inotify_state(user, key);
+ state->inotify_watches--;
+ spin_unlock(&user->inotify_lock);
+}
+
+static inline int inotify_read_watches(struct user_struct *user, void *key)
+{
+ struct inotify_state *state;
+ int ret;
+
+ spin_lock(&user->inotify_lock);
+ state = __find_inotify_state(user, key);
+ ret = state->inotify_watches;
+ spin_unlock(&user->inotify_lock);
+ return ret;
+}
+
+static inline unsigned long inotify_dec_return_dev(struct user_struct *user,
+ void *key)
+{
+ struct inotify_state *state;
+ unsigned long ret;
+
+ spin_lock(&user->inotify_lock);
+ state = __find_inotify_state(user, key);
+ ret = --state->inotify_devs;
+ spin_unlock(&user->inotify_lock);
+
+ return ret;
+}
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index b8d08d0d0a4d..ae7ec2414252 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -86,6 +86,42 @@ struct ctl_table inotify_table[] = {
};
#endif /* CONFIG_SYSCTL */
+
+static int inotify_init_state(struct user_struct *user,
+ void *key)
+{
+ struct inotify_state *state;
+ int ret = 0;
+
+ spin_lock(&user->inotify_lock);
+ state = __find_inotify_count(user, key);
+
+ if (!state) {
+ spin_unlock(&user->inotify_lock);
+ state = kzalloc(sizeof(struct inotify_state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ state->key = current_user_ns();
+ state->inotify_watches = 0;
+ state->inotify_devs = 1;
+
+ spin_lock(&user->inotify_lock);
+ hash_add(user->inotify_tbl, &state->node, (unsigned long)key);
+
+ goto out;
+ } else {
+
+ if (++state->inotify_devs > inotify_max_user_instances) {
+ ret = -EMFILE;
+ goto out;
+ }
+ }
+out:
+ spin_unlock(&user->inotify_lock);
+ return ret;
+}
+
static inline __u32 inotify_arg_to_mask(u32 arg)
{
__u32
[PATCH 4/4] inotify: Don't include inotify.h when !CONFIG_INOTIFY_USER
Signed-off-by: Nikolay Borisov --- fs/notify/fdinfo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c index fd98e5100cab..62068f89d144 100644 --- a/fs/notify/fdinfo.c +++ b/fs/notify/fdinfo.c @@ -13,7 +13,10 @@ #include #include +#ifdef CONFIG_INOTIFY_USER #include "inotify/inotify.h" +#endif + #include "../fs/mount.h" #if defined(CONFIG_PROC_FS) -- 2.5.0
[PATCH 3/4] misc: Rename the HASH_SIZE macro
This change is required since the inotify-per-namespace code added
hashtable.h to the include list of sched.h. This in turn causes
compiler warnings since HASH_SIZE is being defined in multiple
locations
Signed-off-by: Nikolay Borisov
---
fs/logfs/dir.c | 6 +++---
net/ipv6/ip6_gre.c | 8
net/ipv6/ip6_tunnel.c| 10 +-
net/ipv6/ip6_vti.c | 10 +-
net/ipv6/sit.c | 10 +-
security/keys/encrypted-keys/encrypted.c | 32
6 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/fs/logfs/dir.c b/fs/logfs/dir.c
index 2d5336bd4efd..bcd754d216bd 100644
--- a/fs/logfs/dir.c
+++ b/fs/logfs/dir.c
@@ -95,7 +95,7 @@ static int beyond_eof(struct inode *inode, loff_t bix)
* of each character and pick a prime nearby, preferably a bit-sparse
* one.
*/
-static u32 hash_32(const char *s, int len, u32 seed)
+static u32 logfs_hash_32(const char *s, int len, u32 seed)
{
u32 hash = seed;
int i;
@@ -159,7 +159,7 @@ static struct page *logfs_get_dd_page(struct inode *dir,
struct dentry *dentry)
struct qstr *name = &dentry->d_name;
struct page *page;
struct logfs_disk_dentry *dd;
- u32 hash = hash_32(name->name, name->len, 0);
+ u32 hash = logfs_hash_32(name->name, name->len, 0);
pgoff_t index;
int round;
@@ -370,7 +370,7 @@ static int logfs_write_dir(struct inode *dir, struct dentry
*dentry,
{
struct page *page;
struct logfs_disk_dentry *dd;
- u32 hash = hash_32(dentry->d_name.name, dentry->d_name.len, 0);
+ u32 hash = logfs_hash_32(dentry->d_name.name, dentry->d_name.len, 0);
pgoff_t index;
int round, err;
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index af503f518278..b73b4dc5c7ad 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -62,11 +62,11 @@ module_param(log_ecn_error, bool, 0644);
MODULE_PARM_DESC(log_ecn_error, "Log packets received with corrupted ECN");
#define HASH_SIZE_SHIFT 5
-#define HASH_SIZE (1 << HASH_SIZE_SHIFT)
+#define IP6G_HASH_SIZE (1 << HASH_SIZE_SHIFT)
static int ip6gre_net_id __read_mostly;
struct ip6gre_net {
- struct ip6_tnl __rcu *tunnels[4][HASH_SIZE];
+ struct ip6_tnl __rcu *tunnels[4][IP6G_HASH_SIZE];
struct net_device *fb_tunnel_dev;
};
@@ -96,7 +96,7 @@ static void ip6gre_tnl_link_config(struct ip6_tnl *t, int
set_mtu);
will match fallback tunnel.
*/
-#define HASH_KEY(key) (((__force u32)key^((__force u32)key>>4))&(HASH_SIZE -
1))
+#define HASH_KEY(key) (((__force u32)key^((__force
u32)key>>4))&(IP6G_HASH_SIZE - 1))
static u32 HASH_ADDR(const struct in6_addr *addr)
{
u32 hash = ipv6_addr_hash(addr);
@@ -1086,7 +1086,7 @@ static void ip6gre_destroy_tunnels(struct net *net,
struct list_head *head)
for (prio = 0; prio < 4; prio++) {
int h;
- for (h = 0; h < HASH_SIZE; h++) {
+ for (h = 0; h < IP6G_HASH_SIZE; h++) {
struct ip6_tnl *t;
t = rtnl_dereference(ign->tunnels[prio][h]);
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 7b0481e3738f..50b57a435f05 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -64,8 +64,8 @@ MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("ip6tnl");
MODULE_ALIAS_NETDEV("ip6tnl0");
-#define HASH_SIZE_SHIFT 5
-#define HASH_SIZE (1 << HASH_SIZE_SHIFT)
+#define IP6_HASH_SIZE_SHIFT 5
+#define IP6_HASH_SIZE (1 << IP6_HASH_SIZE_SHIFT)
static bool log_ecn_error = true;
module_param(log_ecn_error, bool, 0644);
@@ -75,7 +75,7 @@ static u32 HASH(const struct in6_addr *addr1, const struct
in6_addr *addr2)
{
u32 hash = ipv6_addr_hash(addr1) ^ ipv6_addr_hash(addr2);
- return hash_32(hash, HASH_SIZE_SHIFT);
+ return hash_32(hash, IP6_HASH_SIZE_SHIFT);
}
static int ip6_tnl_dev_init(struct net_device *dev);
@@ -87,7 +87,7 @@ struct ip6_tnl_net {
/* the IPv6 tunnel fallback device */
struct net_device *fb_tnl_dev;
/* lists for storing tunnels in use */
- struct ip6_tnl __rcu *tnls_r_l[HASH_SIZE];
+ struct ip6_tnl __rcu *tnls_r_l[IP6_HASH_SIZE];
struct ip6_tnl __rcu *tnls_wc[1];
struct ip6_tnl __rcu **tnls[2];
};
@@ -2031,7 +2031,7 @@ static void __net_exit ip6_tnl_destroy_tunnels(struct net
*net)
if (dev->rtnl_link_ops == &ip6_link_ops)
unregister_netdevice_queue(dev, &list);
- for (h = 0; h < HASH_SIZE; h++) {
+ for (h = 0; h < IP6_HASH_SIZE; h++) {
t = rtnl_dereference(ip6n->tnls_r_l[h]);
while (t) {
/* If dev is in the same netns, it has already
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index d90a11f14040..30e242140909 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip
[RFC PATCH 0/4] Make inotify instance/watches be accounted per userns
Currently the inotify instances/watches are being accounted in the user_struct structure. This means that in setups where multiple users in unprivileged containers map to the same underlying real user (e.g. user_struct) the inotify limits are going to be shared as well which can lead to unplesantries. This is a problem since any user inside any of the containers can potentially exhaust the instance/watches limit which in turn might prevent certain services from other containers from starting. The solution I propose is rather simple, instead of accounting the watches/instances per user_struct, start accounting them in a hashtable, where the index used is the hashed pointer of the userns. This way the administrator needn't set the inotify limits very high and also the risk of one container breaching the limits and affecting every other container is alleviated. I have performed functional testing to validate that limits in different namespaces are indeed separate, as well as running multiple inotify stressers from stress-ng to ensure I haven't introduced any race conditions. This series is based on 4.7-rc1 (and applies cleanly on 4.4.10) and consist of the following 4 patches: Patch 1: This introduces the necessary structure and code changes. Including hashtable.h to sched.h causes some warnings in files which define HAS_SIZE macro, patch 3 fixes this by doing mechanical rename. Patch 2: This patch flips the inotify code to user the new infrastructure. Patch 3: This is a simple mechanical rename of conflicting definitions with hashtable.h's HASH_SIZE macro. I'm happy about comments how I should go about this. Patch 4: This is a rather self-container patch and can go irrespective of whether the series is accepted, it's needed so that building the kernel with !CONFIG_INOTIFY_USER doesn't fail (with patch 1 being applied). However, fdinfo.c doesn't really need inotify.h Nikolay Borisov (4): inotify: Add infrastructure to account inotify limits per-namespace inotify: Convert inotify limits to be accounted per-realuser/per-namespace misc: Rename the HASH_SIZE macro inotify: Don't include inotify.h when !CONFIG_INOTIFY_USER fs/logfs/dir.c | 6 +-- fs/notify/fdinfo.c | 3 ++ fs/notify/inotify/inotify.h | 68 fs/notify/inotify/inotify_fsnotify.c | 14 ++- fs/notify/inotify/inotify_user.c | 57 ++ include/linux/fsnotify_backend.h | 1 + include/linux/sched.h| 5 ++- kernel/user.c| 13 ++ net/ipv6/ip6_gre.c | 8 ++-- net/ipv6/ip6_tunnel.c| 10 ++--- net/ipv6/ip6_vti.c | 10 ++--- net/ipv6/sit.c | 10 ++--- security/keys/encrypted-keys/encrypted.c | 32 +++ 13 files changed, 189 insertions(+), 48 deletions(-) -- 2.5.0
Re: [PATCH] dma-mapping: Simplify get_dma_ops() control flow
Looks fine, Reviewed-by: Christoph Hellwig
[PATCH 2/4] inotify: Convert inotify limits to be accounted per-realuser/per-namespace
Signed-off-by: Nikolay Borisov
---
fs/notify/inotify/inotify_fsnotify.c | 14 +-
fs/notify/inotify/inotify_user.c | 23 +++
include/linux/sched.h| 2 --
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/fs/notify/inotify/inotify_fsnotify.c
b/fs/notify/inotify/inotify_fsnotify.c
index 2cd900c2c737..efaeec3f2e26 100644
--- a/fs/notify/inotify/inotify_fsnotify.c
+++ b/fs/notify/inotify/inotify_fsnotify.c
@@ -166,7 +166,19 @@ static void inotify_free_group_priv(struct fsnotify_group
*group)
idr_for_each(&group->inotify_data.idr, idr_callback, group);
idr_destroy(&group->inotify_data.idr);
if (group->inotify_data.user) {
- atomic_dec(&group->inotify_data.user->inotify_devs);
+ struct user_struct *user = group->inotify_data.user;
+ void *key = group->inotify_data.userns_ptr;
+ struct inotify_state *state;
+
+ spin_lock(&user->inotify_lock);
+ state = __find_inotify_state(user, key);
+ if (--state->inotify_devs == 0)
+ hash_del(&state->node);
+ spin_unlock(&user->inotify_lock);
+
+ if (state->inotify_devs == 0)
+ kfree(state);
+
free_uid(group->inotify_data.user);
}
}
diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index ae7ec2414252..e7cc4eaa838f 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -94,7 +94,7 @@ static int inotify_init_state(struct user_struct *user,
int ret = 0;
spin_lock(&user->inotify_lock);
- state = __find_inotify_count(user, key);
+ state = __find_inotify_state(user, key);
if (!state) {
spin_unlock(&user->inotify_lock);
@@ -536,7 +536,8 @@ void inotify_ignored_and_remove_idr(struct fsnotify_mark
*fsn_mark,
/* remove this mark from the idr */
inotify_remove_from_idr(group, i_mark);
- atomic_dec(&group->inotify_data.user->inotify_watches);
+ inotify_dec_watches(group->inotify_data.user,
+ group->inotify_data.userns_ptr);
}
/* ding dong the mark is dead */
@@ -609,6 +610,8 @@ static int inotify_new_watch(struct fsnotify_group *group,
int ret;
struct idr *idr = &group->inotify_data.idr;
spinlock_t *idr_lock = &group->inotify_data.idr_lock;
+ struct user_struct *user = group->inotify_data.user;
+ void *key = group->inotify_data.userns_ptr;
mask = inotify_arg_to_mask(arg);
@@ -621,7 +624,7 @@ static int inotify_new_watch(struct fsnotify_group *group,
tmp_i_mark->wd = -1;
ret = -ENOSPC;
- if (atomic_read(&group->inotify_data.user->inotify_watches) >=
inotify_max_user_watches)
+ if (inotify_read_watches(user, key) >= inotify_max_user_watches)
goto out_err;
ret = inotify_add_to_idr(idr, idr_lock, tmp_i_mark);
@@ -638,7 +641,7 @@ static int inotify_new_watch(struct fsnotify_group *group,
}
/* increment the number of watches the user has */
- atomic_inc(&group->inotify_data.user->inotify_watches);
+ inotify_inc_watches(user, key);
/* return the watch descriptor for this new mark */
ret = tmp_i_mark->wd;
@@ -669,6 +672,9 @@ static struct fsnotify_group *inotify_new_group(unsigned
int max_events)
{
struct fsnotify_group *group;
struct inotify_event_info *oevent;
+ struct user_struct *user = get_current_user();
+ void *key = current_user_ns();
+ int ret;
group = fsnotify_alloc_group(&inotify_fsnotify_ops);
if (IS_ERR(group))
@@ -689,12 +695,13 @@ static struct fsnotify_group *inotify_new_group(unsigned
int max_events)
spin_lock_init(&group->inotify_data.idr_lock);
idr_init(&group->inotify_data.idr);
- group->inotify_data.user = get_current_user();
+ group->inotify_data.user = user;
+ group->inotify_data.userns_ptr = key;
- if (atomic_inc_return(&group->inotify_data.user->inotify_devs) >
- inotify_max_user_instances) {
+ ret = inotify_init_state(user, key);
+ if (ret < 0) {
fsnotify_destroy_group(group);
- return ERR_PTR(-EMFILE);
+ return ERR_PTR(ret);
}
return group;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0c55d951d0bb..8f589b32ed15 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -842,8 +842,6 @@ struct user_struct {
#ifdef CONFIG_INOTIFY_USER
spinlock_t inotify_lock;
DECLARE_HASHTABLE(inotify_tbl, 6);
- atomic_t inotify_watches; /* How many inotify watches does this user
have? */
- atomic_t inotify_devs; /* How many inotify devs does this user have
opened? */
#endif
#ifdef CONFIG_FANOTIFY
atomic_t fanotify_listeners;
-
Re: [PATCH 1/5] PCI: Add helpers to request/release memory and I/O regions
On Tue, May 31, 2016 at 02:05:09PM +0200, Johannes Thumshirn wrote:
> Add helpers to request and release a device's memory or I/O regions.
>
> With these helpers in place, one does not need to select a device's memory or
> I/O regions with pci_select_bars() prior to requesting or releasing them.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Johannes Thumshirn
> ---
> include/linux/pci.h | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 932ec74..846f4cf 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2007,6 +2007,35 @@ static inline bool pci_is_dev_assigned(struct pci_dev
> *pdev)
> return (pdev->dev_flags & PCI_DEV_FLAGS_ASSIGNED) ==
> PCI_DEV_FLAGS_ASSIGNED;
> }
>
> +static inline int
> +pci_request_io_regions(struct pci_dev *pdev, const char *name)
> +{
> + return pci_request_selected_regions(pdev,
> + pci_select_bars(pdev,
> IORESOURCE_IO), name);
Needs a little indentation tweak to not spill over 80 characters. Two
tabs should be plenty indentation for the continuation of function
arguments. Ditto for the other functions,
Otherwise looks fine:
Reviewed-by: Christoph Hellwig
Re: [PATCH 2/5] NVMe: Use pci_(request|release)_mem_regions
Looks fine, Reviewed-by: Christoph Hellwig
Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched domain build-up
On Wed, Jun 01, 2016 at 07:07:13AM +0200, Mike Galbraith wrote: > On Tue, 2016-05-31 at 09:31 +0800, Yuyang Du wrote: > > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote: > > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote: > > > > The SD_BALANCE_WAKE is irrelevant in the contexts of these two removals, > > > > and in addition SD_BALANCE_WAKE is not and should not be set in any > > > > sched_domain flags so far. > > > > > > This Changelog doesn't make any sense... > > > > How? SD_BALANCE_WAKE is not in any sched_domain flags (sd->flags), even if > > it is, it is not used anywhere, no? > > If the user chooses to set SD_BALANCE_WAKE in sd->flags, it is in fact > used. It's just not turned on by default due to full balance on every > wakeup being far too painful to do by default. Yup. Up to this point, we don't have any disagreement. And I don't think we have any disagreement conceptually. What the next patch really does is: (1) we don't remove SD_BALANCE_WAKE as an important sched_domain flag, on the contrary, we strengthen it. (2) the semantic of SD_BALANCE_WAKE is currently represented by SD_WAKE_AFFINE, we actually remove this representation. (3) regarding the semantic of SD_WAKE_AFFINE, it is really not about selecting waker CPU or about the fast path. Conceptually, it is just saying the waker CPU is a valid and important candidate if SD_BALANCE_WAKE, which is just so obvious, so I don't think it deserves to be a separate sched_domain flag. (4) the outcome is, if SD_BALANCE_WAKE, we definitely will/should try waker CPU, and if !SD_BALANCE_WAKE, we don't try waker CPU. So nothing functional is changed.
Re: [PATCH 3/5] scsi: Use pci_(request|release)_mem_regions
On Tue, May 31, 2016 at 02:05:11PM +0200, Johannes Thumshirn wrote: > Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at > hand, use it in the lpfc driver. This should read lpfc instead of scsi in the subject line. Also the request side of the patch seems to be missing.
Re: [PATCH 1/2] clocksource: Add Oxford Semiconductor RPS Dual Timer
On 06/01/2016 09:03 AM, Thomas Gleixner wrote:
> On Tue, 31 May 2016, Neil Armstrong wrote:
>> +static int oxnas_rps_timer_shutdown(struct clock_event_device *evt)
>> +{
>> +struct oxnas_rps_timer *rps =
>> +container_of(evt, struct oxnas_rps_timer, clkevent);
>> +
>> +if (!clockevent_state_periodic(evt))
>> +return 0;
>
> So if the timer is in oneshot mode, then you just leave it enabled. What's the
> rationale of this?
Indeed, there is no rationale.
Fixed in v2.
>> +
>> +oxnas_rps_timer_config(rps, 0, 0);
>
> Thanks,
>
> tglx
>
Thanks,
Neil
Re: [PATCH 5/5] ethernet: Use pci_(request|release)_mem_regions
On Tue, May 31, 2016 at 02:05:13PM +0200, Johannes Thumshirn wrote: > Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at > hand, use it in the ethernet drivers. This should probably be one patch per driver.
Re: kvm: GPF in kvm_lapic_latched_init
On Tue, May 31, 2016 at 12:35 PM, Paolo Bonzini wrote: > > > On 08/01/2016 19:42, Dmitry Vyukov wrote: >> Hello, >> >> The following program triggers GPF in kvm_lapic_latched_init if run in >> a parallel loop: >> https://gist.githubusercontent.com/dvyukov/524b398f379440b21115/raw/9627095f57a72501fb51bf7565471d31732b/gistfile1.txt > > I've noticed that the program here tends to segfault a lot, even before > reaching the kernel. Is this intended? Yes.
Re: [PATCH] char/mwave: remove custom BOOLEAN type
On 31/05/2016 at 22:29:56 +0200, Arnd Bergmann wrote :
> The mwave driver has its own macros for the BOOLEAN type and the
> TRUE/FALSE values. This is redundant because the kernel already
> has bool/true/false, and it clashes with the ACPI headers that
> also define these types. The linux/acpi.h header is now included
> implicitly from mwave through the mc146818rtc.h header, as
> reported by Stephen Rothwell:
>
> In file included from drivers/char/mwave/smapi.c:51:0:
> drivers/char/mwave/smapi.h:52:0: warning: "TRUE" redefined
> #define TRUE 1
> ^
> In file included from include/acpi/acpi.h:58:0,
> from include/linux/acpi.h:33,
> from include/linux/mc146818rtc.h:21,
> from drivers/char/mwave/smapi.c:50:
> include/acpi/actypes.h:438:0: note: this is the location of the previous
> definition
> #define TRUE(1 == 1)
> ^
>
> This removes the private types from mwave and uses the standard
> types instead.
>
> Signed-off-by: Arnd Bergmann
> Fixes: fd09cc80165c ("rtc: cmos: move mc146818rtc code out of
> asm-generic/rtc.h")
Reviewed-by: Alexandre Belloni
I guess you used sed anyway because they got changed in the strings as
well.
> ---
> drivers/char/mwave/3780i.c | 64
> ++--
> drivers/char/mwave/3780i.h | 8 +++---
> drivers/char/mwave/mwavedd.c | 42 ++---
> drivers/char/mwave/mwavedd.h | 14 +-
> drivers/char/mwave/smapi.c | 4 +--
> drivers/char/mwave/smapi.h | 6 +
> drivers/char/mwave/tp3780i.c | 52 +--
> 7 files changed, 93 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/char/mwave/3780i.c b/drivers/char/mwave/3780i.c
> index 28740046bc83..972c40a19629 100644
> --- a/drivers/char/mwave/3780i.c
> +++ b/drivers/char/mwave/3780i.c
> @@ -124,7 +124,7 @@ static void dsp3780I_WriteGenCfg(unsigned short
> usDspBaseIO, unsigned uIndex,
> MKBYTE(rSlaveControl));
>
> rSlaveControl_Save = rSlaveControl;
> - rSlaveControl.ConfigMode = TRUE;
> + rSlaveControl.ConfigMode = true;
>
> PRINTK_2(TRACE_3780I,
> "3780i::dsp3780i_WriteGenCfg entry rSlaveControl+ConfigMode
> %x\n",
> @@ -155,7 +155,7 @@ unsigned char dsp3780I_ReadGenCfg(unsigned short
> usDspBaseIO,
>
> MKBYTE(rSlaveControl) = InByteDsp(DSP_IsaSlaveControl);
> rSlaveControl_Save = rSlaveControl;
> - rSlaveControl.ConfigMode = TRUE;
> + rSlaveControl.ConfigMode = true;
> OutByteDsp(DSP_IsaSlaveControl, MKBYTE(rSlaveControl));
> OutByteDsp(DSP_ConfigAddress, (unsigned char) uIndex);
> ucValue = InByteDsp(DSP_ConfigData);
> @@ -230,7 +230,7 @@ int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS *
> pSettings,
> rUartCfg1.BaseIO = 3;
> break;
> }
> - rUartCfg2.Enable = TRUE;
> + rUartCfg2.Enable = true;
> }
>
> rHBridgeCfg1.Reserved = rHBridgeCfg2.Reserved = 0;
> @@ -238,7 +238,7 @@ int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS *
> pSettings,
> rHBridgeCfg1.IrqPulse = pSettings->bDspIrqPulse;
> rHBridgeCfg1.Irq = (unsigned char) pIrqMap[pSettings->usDspIrq];
> rHBridgeCfg1.AccessMode = 1;
> - rHBridgeCfg2.Enable = TRUE;
> + rHBridgeCfg2.Enable = true;
>
>
> rBusmasterCfg2.Reserved = 0;
> @@ -278,8 +278,8 @@ int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS *
> pSettings,
> * soft-reset active for 10ms.
> */
> rSlaveControl.ClockControl = 0;
> - rSlaveControl.SoftReset = TRUE;
> - rSlaveControl.ConfigMode = FALSE;
> + rSlaveControl.SoftReset = true;
> + rSlaveControl.ConfigMode = false;
> rSlaveControl.Reserved = 0;
>
> PRINTK_4(TRACE_3780I,
> @@ -302,7 +302,7 @@ int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS *
> pSettings,
> for (i = 0; i < 11; i++)
> udelay(2000);
>
> - rSlaveControl.SoftReset = FALSE;
> + rSlaveControl.SoftReset = false;
> OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl));
>
> MKWORD(tval) = InWordDsp(DSP_IsaSlaveControl);
> @@ -326,10 +326,10 @@ int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS *
> pSettings,
> }
>
>
> - rHBridgeControl.EnableDspInt = FALSE;
> - rHBridgeControl.MemAutoInc = TRUE;
> - rHBridgeControl.IoAutoInc = FALSE;
> - rHBridgeControl.DiagnosticMode = FALSE;
> + rHBridgeControl.EnableDspInt = false;
> + rHBridgeControl.MemAutoInc = true;
> + rHBridgeControl.IoAutoInc = false;
> + rHBridgeControl.DiagnosticMode = false;
>
> PRINTK_3(TRACE_3780I,
> "3780i::dsp3780i_EnableDSP DSP_HBridgeControl %x
> rHBridgeControl %x\n",
> @@ -345,7 +345,7 @@ int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS *
> pSettings,
> ChipID = ReadMsaCfg(DSP_ChipID);
>
> PRINTK_2(TRACE_3780I,
> - "3780i::dsp3780I_EnableDSP
[PATCH v3 09/12] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
device. The pwrseq device will be used by USB hub to cycle the power
before activating ports.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/core/hub.h | 3 +++
drivers/usb/core/port.c | 15 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e22aae..68ca89780d26 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -24,6 +24,8 @@
#include
#include "usb.h"
+struct pwrseq;
+
struct usb_hub {
struct device *intfdev; /* the "interface" device */
struct usb_device *hdev;
@@ -101,6 +103,7 @@ struct usb_port {
struct usb_dev_state *port_owner;
struct usb_port *peer;
struct dev_pm_qos_request *req;
+ struct pwrseq *pwrseq;
enum usb_port_connect_type connect_type;
usb_port_location_t location;
struct mutex status_lock;
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 460c855be0d0..89b9bdfc7061 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+#include
#include "hub.h"
@@ -526,6 +528,14 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
port1)
return retval;
}
+ port_dev->dev.of_node = usb_of_get_child_node(hdev->dev.parent->of_node,
+ port1);
+ port_dev->pwrseq = pwrseq_alloc(&port_dev->dev, "usb-pwrseq");
+ if (IS_ERR(port_dev->pwrseq)) {
+ device_unregister(&port_dev->dev);
+ return PTR_ERR(port_dev->pwrseq);
+ }
+
find_and_link_peer(hub, port1);
/*
@@ -567,8 +577,13 @@ void usb_hub_remove_port_device(struct usb_hub *hub, int
port1)
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_port *peer;
+ pwrseq_power_off(port_dev->pwrseq);
+
peer = port_dev->peer;
if (peer)
unlink_peers(port_dev, peer);
+
+ pwrseq_free(port_dev->pwrseq);
+ port_dev->pwrseq = NULL;
device_unregister(&port_dev->dev);
}
--
1.9.1
[PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)
Hi,
My third approach for a USB power sequence which fixes usb3503+lan
on Odroid U3 board if it was initialized by bootloader
(e.g. for TFTP boot).
Changes since v2
1. Add Javier's reviewed-by tags. Address some comments.
2. Re-use existing properties for GPIOs etc by pwrseq-simple
driver. New property is still added: "power-sequence".
I tried to address and do according to Rob's comments.
Please look at patch 6/12 ("power: pwrseq: simple: Add support
for regulator and generic property") for bindings and the
new code around matching "power-sequence" property.
3. I marked the usb code as "EXAMPLE" because that part
is left to Peter Chen.
Problem
===
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
is required, e.g. by suspend to RAM. The actual TFTP boot does
not have to happen. Just "usb start" from U-Boot is sufficient.
>From the schematics, the regulator is a supply only to LAN, however
without toggling it off/on, the usb3503 hub won appear neither.
Solution
This is very similar to the MMC pwrseq behavior so the idea is to:
1. Move MMC pwrseq drivers to generic place,
2. Extend the pwrseq-simple with regulator toggling,
3. Add support to USB hub and port core for pwrseq,
4. Toggle the regulator when needed.
Best regards,
Krzysztof
Krzysztof Kozlowski (12):
power/mmc: Move pwrseq drivers to power/pwrseq
MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq
power: pwrseq: Enable COMPILE_TEST for drivers
power: pwrseq: Remove mmc prefix from mmc_pwrseq
power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
power: pwrseq: simple: Add support for regulator and generic property
power: pwrseq: Add support for USB hubs with external power
usb: hub: Handle deferred probe
EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
EXAMPLE CODE: usb: hub: Power sequence the ports on activation
ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on
Odroid U3
.../pwrseq/pwrseq-emmc.txt}| 0
.../pwrseq/pwrseq-simple.txt} | 29 +++-
MAINTAINERS| 9 ++
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +
drivers/mmc/Kconfig| 2 -
drivers/mmc/core/Makefile | 3 -
drivers/mmc/core/core.c| 8 +-
drivers/mmc/core/host.c| 2 +-
drivers/mmc/core/pwrseq.c | 110 ---
drivers/mmc/core/pwrseq.h | 52 ---
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 22 ++-
drivers/power/pwrseq/Makefile | 3 +
drivers/power/pwrseq/pwrseq.c | 153 +
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 17 +--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 110 ---
drivers/usb/core/hub.c | 16 ++-
drivers/usb/core/hub.h | 3 +
drivers/usb/core/port.c| 15 ++
include/linux/mmc/host.h | 4 +-
include/linux/pwrseq.h | 63 +
22 files changed, 414 insertions(+), 214 deletions(-)
rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-emmc.txt =>
power/pwrseq/pwrseq-emmc.txt} (100%)
rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-simple.txt =>
power/pwrseq/pwrseq-simple.txt} (53%)
delete mode 100644 drivers/mmc/core/pwrseq.c
delete mode 100644 drivers/mmc/core/pwrseq.h
rename drivers/{mmc/core => power/pwrseq}/Kconfig (60%)
create mode 100644 drivers/power/pwrseq/Makefile
create mode 100644 drivers/power/pwrseq/pwrseq.c
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (88%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (52%)
create mode 100644 include/linux/pwrseq.h
--
1.9.1
[PATCH v3 05/12] power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
The power sequence hooks (mmc_pwrseq_pre_power_on(),
mmc_pwrseq_post_power_on() and mmc_pwrseq_power_off()) can be made more
generic to allow re-use in other subsystems. They do not need to take
pointer to struct mmc_host but instead the struct pwrseq should be
sufficient.
Remove the "mmc" prefix and use the pointer to struct pwrseq as
argument.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/mmc/core/core.c | 6 +++---
drivers/power/pwrseq/pwrseq.c| 24 +---
drivers/power/pwrseq/pwrseq_emmc.c | 6 ++
drivers/power/pwrseq/pwrseq_simple.c | 14 ++
include/linux/pwrseq.h | 18 +-
5 files changed, 29 insertions(+), 39 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index edefc3fbebe6..09a4722f9037 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1719,7 +1719,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
if (host->ios.power_mode == MMC_POWER_ON)
return;
- mmc_pwrseq_pre_power_on(host);
+ pwrseq_pre_power_on(host->pwrseq);
host->ios.vdd = fls(ocr) - 1;
host->ios.power_mode = MMC_POWER_UP;
@@ -1740,7 +1740,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
*/
mmc_delay(10);
- mmc_pwrseq_post_power_on(host);
+ pwrseq_post_power_on(host->pwrseq);
host->ios.clock = host->f_init;
@@ -1759,7 +1759,7 @@ void mmc_power_off(struct mmc_host *host)
if (host->ios.power_mode == MMC_POWER_OFF)
return;
- mmc_pwrseq_power_off(host);
+ pwrseq_power_off(host->pwrseq);
host->ios.clock = 0;
host->ios.vdd = 0;
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 9c665821f890..495a19d3c30b 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -52,32 +52,26 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
-void mmc_pwrseq_pre_power_on(struct mmc_host *host)
+void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->pre_power_on)
- pwrseq->ops->pre_power_on(host);
+ pwrseq->ops->pre_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_pre_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_pre_power_on);
-void mmc_pwrseq_post_power_on(struct mmc_host *host)
+void pwrseq_post_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->post_power_on)
- pwrseq->ops->post_power_on(host);
+ pwrseq->ops->post_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_post_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_post_power_on);
-void mmc_pwrseq_power_off(struct mmc_host *host)
+void pwrseq_power_off(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->power_off)
- pwrseq->ops->power_off(host);
+ pwrseq->ops->power_off(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_power_off);
+EXPORT_SYMBOL_GPL(pwrseq_power_off);
void mmc_pwrseq_free(struct mmc_host *host)
{
diff --git a/drivers/power/pwrseq/pwrseq_emmc.c
b/drivers/power/pwrseq/pwrseq_emmc.c
index a68ac9a68e04..dbb7e753beb2 100644
--- a/drivers/power/pwrseq/pwrseq_emmc.c
+++ b/drivers/power/pwrseq/pwrseq_emmc.c
@@ -19,8 +19,6 @@
#include
#include
-#include
-
struct mmc_pwrseq_emmc {
struct pwrseq pwrseq;
struct notifier_block reset_nb;
@@ -37,9 +35,9 @@ static void __mmc_pwrseq_emmc_reset(struct mmc_pwrseq_emmc
*pwrseq)
udelay(200);
}
-static void mmc_pwrseq_emmc_reset(struct mmc_host *host)
+static void mmc_pwrseq_emmc_reset(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(host->pwrseq);
+ struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(_pwrseq);
__mmc_pwrseq_emmc_reset(pwrseq);
}
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index d5fbd653153e..93807a6ef162 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -18,8 +18,6 @@
#include
#include
-#include
-
struct mmc_pwrseq_simple {
struct pwrseq pwrseq;
bool clk_enabled;
@@ -46,9 +44,9 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
mmc_pwrseq_simple *pwrseq,
}
}
-static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+static void mmc_pwrseq_simple_pre_power_on(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(host->pwrseq);
+ struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
if (!IS_ERR(pwrseq->ext_clk) && !pwrseq->clk_enabled) {
clk_prepare_enable(pwrseq->ext_clk);
@@ -58,16 +56,16 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host
*host
[lkp] [oom_reaper] df1e2f5663: EIP: [<81e30134>] mmput_async+0x9/0x6b SS:ESP 0068:819a5e78
FYI, we noticed the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit df1e2f56632ddf17186f7036a3bd809d3aed8fd8 ("oom_reaper: close race with
exiting task")
on test machine: vm-lkp-wsx03-openwrt-i386: 1 threads qemu-system-i386
-enable-kvm with 192M memory
caused below changes:
++++
|| dea6c8c672 | df1e2f5663 |
++++
| boot_successes | 23 | 18 |
| boot_failures | 3 | 8 |
| invoked_oom-killer:gfp_mask=0x | 3 | 6 |
| Mem-Info | 3 | 6 |
| Out_of_memory:Kill_process | 3 | 6 |
| backtrace:_do_fork | 1 ||
| backtrace:SyS_clone| 1 ||
| backtrace:process_vm_rw| 1 ||
| backtrace:SyS_process_vm_readv | 1 ||
| backtrace:do_execve| 2 ||
| backtrace:SyS_execve | 2 ||
| backtrace:pgd_alloc| 1 ||
| backtrace:mm_init | 1 ||
| backtrace:vfs_write| 1 ||
| backtrace:SyS_write| 1 ||
| BUG:unable_to_handle_kernel| 0 | 5 |
| Oops | 0 | 5 |
| EIP_is_at_mmput_async | 0 | 5 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 5 |
| backtrace:oom_reaper | 0 | 5 |
| backtrace:do_sys_open | 0 | 1 |
| backtrace:SyS_open | 0 | 1 |
| IP-Config:Auto-configuration_of_network_failed | 0 | 2 |
++++
[ 82.815896] BUG: unable to handle kernel NULL pointer dereference at 0025
[ 82.816733] IP: [<81e30134>] mmput_async+0x9/0x6b
[ 82.817281] *pde =
[ 82.817628] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC
[ 82.818169] CPU: 0 PID: 13 Comm: oom_reaper Not tainted 4.6.0-10870-gdf1e2f5
#1
[ 82.818973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 82.819867] task: 819a2340 ti: 819a4000 task.ti: 819a4000
[ 82.820419] EIP: 0060:[<81e30134>] EFLAGS: 00010246 CPU: 0
[ 82.820988] EIP is at mmput_async+0x9/0x6b
[ 82.821413] EAX: 0001 EBX: 0001 ECX: EDX:
[ 82.822040] ESI: EDI: 819a5e9c EBP: 819a5e7c ESP: 819a5e78
[ 82.822683] DS: 007b ES: 007b FS: GS: SS: 0068
[ 82.823226] CR0: 80050033 CR2: 0025 CR3: 0074 CR4: 0690
[ 82.823864] DR0: 6cd78000 DR1: DR2: DR3:
[ 82.824511] DR6: 0ff0 DR7: 0600
[ 82.824918] Stack:
[ 82.825131] 0001 819a5eec 81ed1467 819a5e94 7de80301
[ 82.826043] 0101 819a5edc 0246 0246 819a5eb0 81e5ca86 819a5edc
819a27e8
[ 82.826968] 819a27e8 00c2 819a5edc 819a5edc 81e50726
[ 82.827881] Call Trace:
[ 82.828147] [<81ed1467>] __oom_reap_task+0x178/0x185
[ 82.828676] [<81e5ca86>] ? put_lock_stats+0xd/0x1d
[ 82.829234] [<81e50726>] ? preempt_count_sub+0x8b/0xce
[ 82.829771] [<81ed18c6>] oom_reaper+0x159/0x190
[ 82.830249] [<81e57fcf>] ? __wake_up_common+0x5f/0x5f
[ 82.830776] [<81ed176d>] ? exit_oom_victim+0x40/0x40
[ 82.831286] [<81e496f1>] kthread+0xad/0xb2
[ 82.831722] [<8231e6a0>] ? _raw_spin_unlock_irq+0x61/0x6e
[ 82.832273] [<8231eec2>] ret_from_kernel_thread+0xe/0x24
[ 82.832824] [<81e49644>] ? __kthread_parkme+0x6e/0x6e
[ 82.89] Code: 2c 50 68 a5 31 62 82 e8 9b af 09 00 58 5a a1 c4 85 9e 82
89 da e8 33 49 0d 00 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 53 e8 cc f7 4e 00 48
24 74 02 eb 56 89 c3 b9 ac 85 9e 82 c7 80 4c 02 00 00 e0
[ 82.836292] EIP: [<81e30134>] mmput_async+0x9/0x6b SS:ESP 0068:819a5e78
[ 82.837000] CR2: 0025
[ 82.837342] ---[ end trace e937cb7742e041b3 ]---
[ 82.837834] Kernel panic - not syncing: Fatal exception
[ 82.838374] Kernel Offset: 0x8e0 from 0x7900 (relocation range:
0x7800-0x847d)
FYI, raw QEMU command line is:
qemu-system-i386 -enable-kvm -kernel
/pkg/linux/i386-randconfig-x0-05271601/gcc-6/df1e2f56632ddf17186f7036a3bd809d3aed8fd8/vmlinuz-4.6.0-10870-gdf1e2f5
-ap
Re: [PATCH 3/5] scsi: Use pci_(request|release)_mem_regions
On Wed, Jun 01, 2016 at 12:59:29AM -0700, Christoph Hellwig wrote: > On Tue, May 31, 2016 at 02:05:11PM +0200, Johannes Thumshirn wrote: > > Now that we do have pci_request_mem_regions() and pci_release_mem_regions() > > at > > hand, use it in the lpfc driver. > > This should read lpfc instead of scsi in the subject line. > > Also the request side of the patch seems to be missing. You're right. I'll be checking why the coccinelle spatch didn't catch it up. -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: script relative shebang
Hi Nicolai,
Yes, I think this is too ugly:
#!/usr/bin/gawk {exit system("/bin/sh -c 'exec \"$(dirname
\"$0\")\"/subdir/catself \"$0\"' " FILENAME);}
Imagine you have that feature in your kernel would you rather use:
#!{dirname}/subdir/catself
You second advice involves changing root fs which is not desirable in
copy-deployment apps (bring all the dependencies)
This more about making kernel "user" friendly.
Thank you.
On 1 June 2016 00:02:05 BST, Nicolai Stange wrote:
>Hi Boris,
>
>Boris Rybalkin writes:
>
>> I would like to know if any changes to parsing '#!' script header
>line
>> are accepted in particular having ability to run interpreter from
>> relative to the script path?
>>
>> Something like:
>>
>> #!{dirname}/python/bin/python
>>
>> Where {dirname} is a special keyword replaced with dirname of a
>script.
>
>Just for the record, this can already be done without any help from the
>kernel:
>
>Assuming the following demonstration directory layout
>
> /subdir/catself
> /relshebang
>
>where catself.sh is your "interpreter":
>
> #!/bin/sh
> tail -n +2 $1
>
>and relshebang is your script file invoking the toy interpreter from
>its
>shebang as follows:
>
>#!/usr/bin/gawk {exit system("/bin/sh -c 'exec \"$(dirname
>\"$0\")\"/subdir/catself \"$0\"' " FILENAME);}
> Hello world.
>
>
>You don't necessarily need to use gawk here, anything being able to do
>system() and taking some code snippet from its first argument will
>certainly work.
>
>If this is too ugly, you could also write your own wrapper a la
>/usr/bin/env and install that at some central location.
>
>
>Best,
>
>Nicolai
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH v3 08/12] usb: hub: Handle deferred probe
Add support for deferred probing to the usb hub. Currently EPROBE_DEFER does not exist in usb hub path but future patches will add it on the port level. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- drivers/usb/core/hub.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index bee13517676f..c421745b84aa 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1733,6 +1733,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) struct usb_endpoint_descriptor *endpoint; struct usb_device *hdev; struct usb_hub *hub; + int ret; desc = intf->cur_altsetting; hdev = interface_to_usbdev(intf); @@ -1852,11 +1853,12 @@ descriptor_error: if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) hub->quirk_check_port_auto_suspend = 1; - if (hub_configure(hub, endpoint) >= 0) + ret = hub_configure(hub, endpoint); + if (ret >= 0) return 0; hub_disconnect(intf); - return -ENODEV; + return ret; } static int -- 1.9.1
[PATCH v3 07/12] power: pwrseq: Add support for USB hubs with external power
Some USB devices on embedded boards have external power supply which has
to be reset in certain conditions. Add pwrseq interface for this.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/pwrseq/pwrseq.c | 47 ++-
include/linux/pwrseq.h| 11 ++
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 495a19d3c30b..722aff4f740f 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -1,7 +1,9 @@
/*
- * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2016 Samsung Electronics
*
* Author: Ulf Hansson
+ * Krzysztof Kozlowski
*
* License terms: GNU General Public License (GPL) version 2
*
@@ -52,6 +54,42 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
+struct pwrseq *pwrseq_alloc(struct device *dev, const char *phandle_name)
+{
+ struct device_node *np;
+ struct pwrseq *p, *ret = NULL;
+
+ np = of_parse_phandle(dev->of_node, phandle_name, 0);
+ if (!np)
+ return NULL;
+
+ mutex_lock(&pwrseq_list_mutex);
+ list_for_each_entry(p, &pwrseq_list, pwrseq_node) {
+ if (p->dev->of_node == np) {
+ if (!try_module_get(p->owner))
+ dev_err(dev,
+ "increasing module refcount failed\n");
+ else
+ ret = p;
+
+ break;
+ }
+ }
+
+ of_node_put(np);
+ mutex_unlock(&pwrseq_list_mutex);
+
+ if (!ret) {
+ dev_dbg(dev, "%s defer probe\n", phandle_name);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ dev_info(dev, "allocated usb-pwrseq\n");
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc);
+
void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
if (pwrseq && pwrseq->ops->pre_power_on)
@@ -84,6 +122,13 @@ void mmc_pwrseq_free(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_free);
+void pwrseq_free(const struct pwrseq *pwrseq)
+{
+ if (pwrseq)
+ module_put(pwrseq->owner);
+}
+EXPORT_SYMBOL_GPL(pwrseq_free);
+
int pwrseq_register(struct pwrseq *pwrseq)
{
if (!pwrseq || !pwrseq->ops || !pwrseq->dev)
diff --git a/include/linux/pwrseq.h b/include/linux/pwrseq.h
index fcc8fd855d4c..6215b3d6350d 100644
--- a/include/linux/pwrseq.h
+++ b/include/linux/pwrseq.h
@@ -31,9 +31,13 @@ void pwrseq_unregister(struct pwrseq *pwrseq);
void pwrseq_pre_power_on(struct pwrseq *pwrseq);
void pwrseq_post_power_on(struct pwrseq *pwrseq);
void pwrseq_power_off(struct pwrseq *pwrseq);
+
int mmc_pwrseq_alloc(struct mmc_host *host);
void mmc_pwrseq_free(struct mmc_host *host);
+struct pwrseq *pwrseq_alloc(struct device *dev, const char *phandle_name);
+void pwrseq_free(const struct pwrseq *pwrseq);
+
#else /* CONFIG_POWER_SEQ */
static inline int pwrseq_register(struct pwrseq *pwrseq)
@@ -44,9 +48,16 @@ static inline void pwrseq_unregister(struct pwrseq *pwrseq)
{}
static inline void pwrseq_pre_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_post_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_power_off(struct pwrseq *pwrseq) {}
+
static inline int mmc_pwrseq_alloc(struct mmc_host *host) { return 0; }
static inline void mmc_pwrseq_free(struct mmc_host *host) {}
+static inline struct pwrseq *pwrseq_alloc(struct device *dev, const char
*phandle_name)
+{
+ return NULL;
+}
+static inline void pwrseq_free(const struct pwrseq *pwrseq) {}
+
#endif /* CONFIG_POWER_SEQ */
#endif /* _LINUX_PWRSEQ_H */
--
1.9.1
[PATCH v3 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
and LAN (smsc95xx) after after successful probing were not visible in the
system ("lsusb").
In such case the devices had to be fully reset before configuring.
Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
in usb3503 HUB are not sufficient. Instead full reset has to be done by
disabling and enabling regulator.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 31cdc036fda4..23e30e4609df 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -99,11 +99,15 @@
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
refclk-frequency = <2400>;
+
+ power-sequence;
+ ext-supply = <&buck8_reg>;
};
&ehci {
port@1 {
status = "okay";
+ usb-pwrseq = <&usb3503>;
};
port@2 {
status = "okay";
--
1.9.1
[PATCH v3 01/12] power/mmc: Move pwrseq drivers to power/pwrseq
The MMC power sequence drivers are useful also outside of MMC world: for
USB devices needed a hard-reset before probing. Before extending and
re-using pwrseq drivers, move them to a new place.
The commit does not introduce significant changes in the pwrseq drivers
code so still all the functions are prefixed with "mmc_pwrseq". However
the MMC-specific pwrseq functions has to be now exported and everything
is hidden not by CONFIG_OF but by new CONFIG_POWER_SEQ option.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
.../pwrseq/pwrseq-emmc.txt}| 0
.../pwrseq/pwrseq-simple.txt} | 0
drivers/mmc/Kconfig| 2 --
drivers/mmc/core/Makefile | 3 ---
drivers/mmc/core/core.c| 2 +-
drivers/mmc/core/host.c| 2 +-
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 18 +-
drivers/power/pwrseq/Makefile | 3 +++
drivers/{mmc/core => power/pwrseq}/pwrseq.c| 8 ++--
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 3 +--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 3 +--
{drivers/mmc/core => include/linux}/pwrseq.h | 6 +++---
14 files changed, 31 insertions(+), 21 deletions(-)
rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-emmc.txt =>
power/pwrseq/pwrseq-emmc.txt} (100%)
rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-simple.txt =>
power/pwrseq/pwrseq-simple.txt} (100%)
rename drivers/{mmc/core => power/pwrseq}/Kconfig (66%)
create mode 100644 drivers/power/pwrseq/Makefile
rename drivers/{mmc/core => power/pwrseq}/pwrseq.c (90%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (99%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (99%)
rename {drivers/mmc/core => include/linux}/pwrseq.h (94%)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-emmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
rename to Documentation/devicetree/bindings/power/pwrseq/pwrseq-emmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
rename to Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f2eeb38efa65..7ade379e0634 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -21,8 +21,6 @@ config MMC_DEBUG
if MMC
-source "drivers/mmc/core/Kconfig"
-
source "drivers/mmc/card/Kconfig"
source "drivers/mmc/host/Kconfig"
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index f007151dfdc6..a901d3cd09d3 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -8,7 +8,4 @@ mmc_core-y := core.o bus.o host.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
quirks.o slot-gpio.o
-mmc_core-$(CONFIG_OF) += pwrseq.o
-obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
-obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8b4dfd45433b..edefc3fbebe6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,6 @@
#include "bus.h"
#include "host.h"
#include "sdio_bus.h"
-#include "pwrseq.h"
#include "mmc_ops.h"
#include "sd_ops.h"
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 1be42fab1a30..1db7d5802adc 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,7 +30,6 @@
#include "core.h"
#include "host.h"
#include "slot-gpio.h"
-#include "pwrseq.h"
#define cls_dev_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 421770ddafa3..2702aca6cd2c 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -511,5 +511,6 @@ config AXP20X_POWER
endif # POWER_SUPPLY
+source "drivers/power/pwrseq/Kconfig"
source "drivers/power/reset/Kconfig"
source "drivers/power/avs/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d448a5..02f9d5da2e76 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_POWER_A
Re: [PATCH v2 3/3] ACPI / button: Send "open" state after boot/resume
On Wed, Jun 1, 2016 at 9:51 AM, Zheng, Lv wrote: > Hi, > > [cut] >> > We could have a parameter (say "send_lid_open_on_resume" or >> > "use_bios_lid_value") in acpi/button.c which would allow people to >> > choose if they want the "new" behavior or the old one. And we could >> > also add some DMI matching for the messed up laptops/tablets where >> we >> > force one or the other quirk. When we agree that user space now >> > behaves gently with us, we could then remove entirely the quirk and >> > the dmi matching. >> > >> > How does that sound? >> [Lv Zheng] >> The choices are in my first revision. >> I could restore it back and re-send this series. >> Also I need to update PATCH 02 to eliminate wrong IS_ERR_VALUE(). > [Lv Zheng] > I forgot to mention. > IMO, if the issue is because of uncertain gaps, not a confirmed BIOS bug, or > a confirmed gap that has to be solved in a spirit of compromise, we should > not add quirks. > We could just provide boot parameters for users to choose. > Because the quirk table could grow bigger and bigger, exceeding our control. > > So I probably would just implement the parameter part, without adding the DMI > entries. > Works for me. I think in Fedora, we might default to keep the current behavior, but document that some tablets need the parameter to be set. As soon as systemd changes its policy, we can change the default value. As for the Surface3, I think the LID state and irq is just not enough robust to be used through the ACPI node PNP0C0D. I get all the information from the touchscreen ACPI Node and the WMI, so I think there might be a way to remove the standard ACPI LID and use our own, or simply override the ACPI call by a different one (through the WMI). It's a shame logind only expects one LID event node :). Cheers, Benjamin
[PATCH v3 11/12] ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
Switch the control of buck8 to GPIO mode. It is faster than I2C/register mode and it is the easiest way to disable it (regulator state is a logical OR state of GPIO and register value). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts index d73aa6c58fe3..31cdc036fda4 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts @@ -74,6 +74,7 @@ regulator-name = "BUCK8_P3V3"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; + maxim,ena-gpios = <&gpa1 1 GPIO_ACTIVE_HIGH>; }; /* VDDQ for MSHC (eMMC card) */ -- 1.9.1
Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources
Hi, Roger Quadros writes: > Implementations might use different IRQs for > host, gadget and OTG so use named interrupt resources > to allow Device tree to specify the 3 interrupts. > > Following are the interrupt names > > Peripheral Interrupt - peripheral > HOST Interrupt - host > OTG Interrupt - otg > > We still maintain backward compatibility for a single named > interrupt for all 3 interrupts (e.g. for dwc3-pci) and > single unnamed interrupt for all 3 interrupts (e.g. old DT). > > Signed-off-by: Roger Quadros > --- > v9: rebased on top of balbi/testing/next breaks dwc3: [ 222.776504] dwc3 dwc3.0.auto: failed to request irq #-6 --> -22 please test -- balbi signature.asc Description: PGP signature
[PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property
Some devices need real hard-reset by cutting the power. During power
sequence turn off and on the regulator, if it is provided.
Additionally add support for instantiating the pwrseq-simple device on a
generic property 'power-sequence'. The device will attach itself to the
node containing the property and parse the node's properties like
reset-gpios, ext-supply etc.
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/power/pwrseq/pwrseq-simple.txt| 29 +++-
drivers/power/pwrseq/pwrseq_simple.c | 85 +-
2 files changed, 107 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
index ce0e76749671..a8c3f13ee83f 100644
--- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
@@ -1,11 +1,17 @@
-* The simple MMC power sequence provider
+* The simple power sequence provider
-The purpose of the simple MMC power sequence provider is to supports a set of
+The purpose of the simple power sequence provider is to supports a set of
common properties between various SOC designs. It thus enables us to use the
same provider for several SOC designs.
-Required properties:
-- compatible : contains "mmc-pwrseq-simple".
+The driver supports two types of bindings:
+1. Separate node
+ Required properties:
+ - compatible : contains "mmc-pwrseq-simple".
+
+2. Property for any node
+ Required properties:
+ - power-sequence
Optional properties:
- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are
asserted
@@ -16,6 +22,7 @@ Optional properties:
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entry:
"ext_clock" (External clock provided to the card).
+- ext-supply : External regulator supply
Example:
@@ -24,4 +31,18 @@ Example:
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
clocks = <&clk_32768_ck>;
clock-names = "ext_clock";
+ ext-supply = <&buck8>;
}
+
+ usb3503@08 {
+ compatible = "smsc,usb3503";
+ reg = <0x08>;
+
+ intn-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
+ connect-gpios = <&gpx3 4 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
+ initial-mode = <1>;
+
+ power-sequence;
+ ext-supply = <&buck8_reg>;
+ };
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index 93807a6ef162..4096261b16a4 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -1,12 +1,15 @@
/*
- * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2016 Samsung Electronics
*
* Author: Ulf Hansson
+ * Krzysztof Kozlowski
*
* License terms: GNU General Public License (GPL) version 2
*
* Simple MMC power sequence management
*/
+#include
#include
#include
#include
@@ -16,13 +19,16 @@
#include
#include
#include
+#include
#include
+#include
struct mmc_pwrseq_simple {
struct pwrseq pwrseq;
bool clk_enabled;
struct clk *ext_clk;
struct gpio_descs *reset_gpios;
+ struct regulator *ext_reg;
};
#define to_pwrseq_simple(p) container_of(p, struct mmc_pwrseq_simple, pwrseq)
@@ -60,6 +66,13 @@ static void mmc_pwrseq_simple_post_power_on(struct pwrseq
*_pwrseq)
{
struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
+ if (pwrseq->ext_reg) {
+ int err;
+
+ err = regulator_enable(pwrseq->ext_reg);
+ WARN_ON_ONCE(err);
+ }
+
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
@@ -73,6 +86,13 @@ static void mmc_pwrseq_simple_power_off(struct pwrseq
*_pwrseq)
clk_disable_unprepare(pwrseq->ext_clk);
pwrseq->clk_enabled = false;
}
+
+ if (pwrseq->ext_reg) {
+ int err;
+
+ err = regulator_disable(pwrseq->ext_reg);
+ WARN_ON_ONCE(err);
+ }
}
static const struct pwrseq_ops mmc_pwrseq_simple_ops = {
@@ -100,12 +120,40 @@ static int mmc_pwrseq_simple_probe(struct platform_device
*pdev)
if (IS_ERR(pwrseq->ext_clk) && PTR_ERR(pwrseq->ext_clk) != -ENOENT)
return PTR_ERR(pwrseq->ext_clk);
+ pwrseq->ext_reg = devm_regulator_get_optional(dev, "ext");
+ if (IS_ERR(pwrseq->ext_reg)) {
+ if (PTR_ERR(pwrseq->ext_reg) == -ENODEV)
+ pwrseq->ext_reg = NULL;
+ else
+ return PTR_ERR(pwrseq->ext_reg);
+ } else {
+ int err;
+ /*
+* Be sure that regulator is off, before the driver will start
+* power sequence. It is likely t
[PATCH v3 04/12] power: pwrseq: Remove mmc prefix from mmc_pwrseq
The "mmc" prefix is no longer needed after moving the pwrseq core code
from mmc/ to power/.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/power/pwrseq/pwrseq.c| 18 +-
drivers/power/pwrseq/pwrseq_emmc.c | 8
drivers/power/pwrseq/pwrseq_simple.c | 8
include/linux/mmc/host.h | 4 ++--
include/linux/pwrseq.h | 20 ++--
5 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 66310d7643cc..9c665821f890 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -21,7 +21,7 @@ static LIST_HEAD(pwrseq_list);
int mmc_pwrseq_alloc(struct mmc_host *host)
{
struct device_node *np;
- struct mmc_pwrseq *p;
+ struct pwrseq *p;
np = of_parse_phandle(host->parent->of_node, "mmc-pwrseq", 0);
if (!np)
@@ -54,7 +54,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
void mmc_pwrseq_pre_power_on(struct mmc_host *host)
{
- struct mmc_pwrseq *pwrseq = host->pwrseq;
+ struct pwrseq *pwrseq = host->pwrseq;
if (pwrseq && pwrseq->ops->pre_power_on)
pwrseq->ops->pre_power_on(host);
@@ -63,7 +63,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_pre_power_on);
void mmc_pwrseq_post_power_on(struct mmc_host *host)
{
- struct mmc_pwrseq *pwrseq = host->pwrseq;
+ struct pwrseq *pwrseq = host->pwrseq;
if (pwrseq && pwrseq->ops->post_power_on)
pwrseq->ops->post_power_on(host);
@@ -72,7 +72,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_post_power_on);
void mmc_pwrseq_power_off(struct mmc_host *host)
{
- struct mmc_pwrseq *pwrseq = host->pwrseq;
+ struct pwrseq *pwrseq = host->pwrseq;
if (pwrseq && pwrseq->ops->power_off)
pwrseq->ops->power_off(host);
@@ -81,7 +81,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_power_off);
void mmc_pwrseq_free(struct mmc_host *host)
{
- struct mmc_pwrseq *pwrseq = host->pwrseq;
+ struct pwrseq *pwrseq = host->pwrseq;
if (pwrseq) {
module_put(pwrseq->owner);
@@ -90,7 +90,7 @@ void mmc_pwrseq_free(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_free);
-int mmc_pwrseq_register(struct mmc_pwrseq *pwrseq)
+int pwrseq_register(struct pwrseq *pwrseq)
{
if (!pwrseq || !pwrseq->ops || !pwrseq->dev)
return -EINVAL;
@@ -101,9 +101,9 @@ int mmc_pwrseq_register(struct mmc_pwrseq *pwrseq)
return 0;
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_register);
+EXPORT_SYMBOL_GPL(pwrseq_register);
-void mmc_pwrseq_unregister(struct mmc_pwrseq *pwrseq)
+void pwrseq_unregister(struct pwrseq *pwrseq)
{
if (pwrseq) {
mutex_lock(&pwrseq_list_mutex);
@@ -111,4 +111,4 @@ void mmc_pwrseq_unregister(struct mmc_pwrseq *pwrseq)
mutex_unlock(&pwrseq_list_mutex);
}
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_unregister);
+EXPORT_SYMBOL_GPL(pwrseq_unregister);
diff --git a/drivers/power/pwrseq/pwrseq_emmc.c
b/drivers/power/pwrseq/pwrseq_emmc.c
index a0583ed46d7f..a68ac9a68e04 100644
--- a/drivers/power/pwrseq/pwrseq_emmc.c
+++ b/drivers/power/pwrseq/pwrseq_emmc.c
@@ -22,7 +22,7 @@
#include
struct mmc_pwrseq_emmc {
- struct mmc_pwrseq pwrseq;
+ struct pwrseq pwrseq;
struct notifier_block reset_nb;
struct gpio_desc *reset_gpio;
};
@@ -54,7 +54,7 @@ static int mmc_pwrseq_emmc_reset_nb(struct notifier_block
*this,
return NOTIFY_DONE;
}
-static const struct mmc_pwrseq_ops mmc_pwrseq_emmc_ops = {
+static const struct pwrseq_ops mmc_pwrseq_emmc_ops = {
.post_power_on = mmc_pwrseq_emmc_reset,
};
@@ -85,7 +85,7 @@ static int mmc_pwrseq_emmc_probe(struct platform_device *pdev)
pwrseq->pwrseq.owner = THIS_MODULE;
platform_set_drvdata(pdev, pwrseq);
- return mmc_pwrseq_register(&pwrseq->pwrseq);
+ return pwrseq_register(&pwrseq->pwrseq);
}
static int mmc_pwrseq_emmc_remove(struct platform_device *pdev)
@@ -93,7 +93,7 @@ static int mmc_pwrseq_emmc_remove(struct platform_device
*pdev)
struct mmc_pwrseq_emmc *pwrseq = platform_get_drvdata(pdev);
unregister_restart_handler(&pwrseq->reset_nb);
- mmc_pwrseq_unregister(&pwrseq->pwrseq);
+ pwrseq_unregister(&pwrseq->pwrseq);
return 0;
}
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index 786f1db53a3f..d5fbd653153e 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -21,7 +21,7 @@
#include
struct mmc_pwrseq_simple {
- struct mmc_pwrseq pwrseq;
+ struct pwrseq pwrseq;
bool clk_enabled;
struct clk *ext_clk;
struct gpio_descs *reset_gpios;
@@ -77,7 +77,7 @@ static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
}
}
-static const struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
+static const
[PATCH v3 10/12] EXAMPLE CODE: usb: hub: Power sequence the ports on activation
The autodetection of attached USB device might not work on certain boards where the power is delivered externally. These devices also might require a hard reset. Use pwrseq for that in USB hub. Signed-off-by: Krzysztof Kozlowski --- drivers/usb/core/hub.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c421745b84aa..46d9f9aedacc 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -1663,6 +1664,15 @@ static int hub_configure(struct usb_hub *hub, usb_hub_adjust_deviceremovable(hdev, hub->descriptor); + /* FIXME: When do the pre-power-on? */ + /* + for (i = 0; i < maxchild; i++) + pwrseq_pre_power_on(hub->ports[i]->pwrseq); + */ + + for (i = 0; i < maxchild; i++) + pwrseq_post_power_on(hub->ports[i]->pwrseq); + hub_activate(hub, HUB_INIT); return 0; -- 1.9.1
[PATCH v3 03/12] power: pwrseq: Enable COMPILE_TEST for drivers
Allow build testing for power sequence drivers. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- drivers/power/pwrseq/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig index 7ecd66ab61f3..c7e9271fd94f 100644 --- a/drivers/power/pwrseq/Kconfig +++ b/drivers/power/pwrseq/Kconfig @@ -10,7 +10,7 @@ if POWER_SEQ config POWER_SEQ_EMMC tristate "HW reset support for eMMC" default y - depends on OF + depends on OF || COMPILE_TEST help This selects Hardware reset support aka pwrseq-emmc for eMMC devices. By default this option is set to y. @@ -21,7 +21,7 @@ config POWER_SEQ_EMMC config POWER_SEQ_SIMPLE tristate "Simple HW reset support for MMC" default y - depends on OF + depends on OF || COMPILE_TEST help This selects simple hardware reset support aka pwrseq-simple for MMC devices. By default this option is set to y. -- 1.9.1
Re: [PATCH 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY
Hi Heiko, On 05/31/2016 05:02 PM, Heiko Stübner wrote: Hi Frank, Am Dienstag, 31. Mai 2016, 14:40:10 schrieb Frank Wang: Signed-off-by: Frank Wang --- .../bindings/phy/phy-rockchip-inno-usb2.txt| 48 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new file mode 100644 index 000..4e537b2 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt @@ -0,0 +1,48 @@ +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK + +Required properties (phy (parent) node): + - compatible: should contain: + * "rockchip,rk3366-usb2phy" + - #clock-cells: should be 0. + - clock-names: specify the 480m output clk name. + +Optional properties: + - vbus_host-gpio: pull gpio high/low to control the host vbus power. sorry for not catching that in our earlier talks, but I believe this should be a regulator instead. See for example vcc5_host1, vcc5v_otg in rk3288-veyron- chromebook.dtsi . That is OK, I will correct it in the next version. +Required nodes: a sub-node is required for each port the phy provides. + The sub-node name is used to identify host or otg port. + +Required properties (port (child) node): + - #phy-cells: must be 0. See ./phy-bindings.txt for details. + - interrupts: irq number for host/otg port. make that something like: Specify an interrupt for each entry in interrupt-names. + - interrupt-names: interrupt name, in line with irq number. make that something like: Shall be "linestate" for the linestate interrupt. Yeah, Got it. --- You might want to add the bvalid and id interrupts for the otg phys as well already - would make handling legacy devicetree files easier. [= if they get specified later, the driver would always need to also handle devicetrees where they aren't specified]. Hmmm! you mean that I can specify these properties into documentation, even if the driver have not handled (implemented) them in current? BR. Frank
Re: [PATCH] char/mwave: remove custom BOOLEAN type
On Wednesday, June 1, 2016 10:00:33 AM CEST Alexandre Belloni wrote:
> On 31/05/2016 at 22:29:56 +0200, Arnd Bergmann wrote :
> > The mwave driver has its own macros for the BOOLEAN type and the
> > TRUE/FALSE values. This is redundant because the kernel already
> > has bool/true/false, and it clashes with the ACPI headers that
> > also define these types. The linux/acpi.h header is now included
> > implicitly from mwave through the mc146818rtc.h header, as
> > reported by Stephen Rothwell:
> >
> > In file included from drivers/char/mwave/smapi.c:51:0:
> > drivers/char/mwave/smapi.h:52:0: warning: "TRUE" redefined
> > #define TRUE 1
> > ^
> > In file included from include/acpi/acpi.h:58:0,
> > from include/linux/acpi.h:33,
> > from include/linux/mc146818rtc.h:21,
> > from drivers/char/mwave/smapi.c:50:
> > include/acpi/actypes.h:438:0: note: this is the location of the previous
> > definition
> > #define TRUE(1 == 1)
> > ^
> >
> > This removes the private types from mwave and uses the standard
> > types instead.
> >
> > Signed-off-by: Arnd Bergmann
> > Fixes: fd09cc80165c ("rtc: cmos: move mc146818rtc code out of
> > asm-generic/rtc.h")
> Reviewed-by: Alexandre Belloni
>
> I guess you used sed anyway because they got changed in the strings as
> well.
>
Yes, that is right. It also makes more sense to adapt the strings at the same
time,
so I left those changes in place.
Arnd
[PATCH v3 02/12] MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq
Before moving pwrseq drivers from drivers/mmc/core/ to drivers/power/, they were maintained by Ulf Hansson. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4f2a75ce5442..71114607502a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9083,6 +9083,15 @@ F: include/linux/power_supply.h F: drivers/power/ X: drivers/power/avs/ +POWER SEQ CORE and DRIVERS +M: Ulf Hansson +L: linux-...@vger.kernel.org +T: git git://git.linaro.org/people/ulf.hansson/mmc.git +S: Maintained +F: drivers/power/pwrseq/ +F: include/linux/pwrseq.h +F: Documentation/devicetree/bindings/power/pwrseq/ + POWER STATE COORDINATION INTERFACE (PSCI) M: Mark Rutland M: Lorenzo Pieralisi -- 1.9.1
Re: [PATCH v5 04/18] arm64: Remove unnecessary of_platform_populate with default match table
On Wed, Jun 01, 2016 at 02:52:57PM +0800, Kefeng Wang wrote: > After patch "of/platform: Add common method to populate default bus", > it is possible for arch code to remove unnecessary callers of > of_platform_populate with default match table. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Arnd Bergmann > Signed-off-by: Kefeng Wang For arm64: Acked-by: Catalin Marinas
Re: [RFC PATCHv2] usb: USB Type-C Connector Class
On Tue, May 31, 2016 at 10:20:34AM -0700, Guenter Roeck wrote: > On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote: > > On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote: > > > On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote: > > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote: > > > > > Hi Oliver, > > > > > > > > > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote: > > > > > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote: > > > > > > > Hi guys, > > > > > > > > > > > > > > I'm attaching a diff instead of full v3. I'm not yet adding > > > > > > > attributes > > > > > > > for the reset and cable_reset. I still don't understand what is > > > > > > > the > > > > > > > case where the userspace would need to be able to tricker reset? > > > > > > > Why > > > > > > > isn't it enough for the userspace to be able to enter/exit modes? > > > > > > > Oliver! Can you please comment? > > > > > > > > > > > > 1. Because we need error handling. > > > > > >Devices crash. Cables will crash. We will get out of sync. > > > > > >You never put yourself in a place where you cannot handle an > > > > > >IO error. > > > > > > 2. Because it is in the spec. We do not second guess the spec. > > > > > >We implement it. > > > > > > > > > > Error conditions and crashes are the responsibility of the USB PD > > > > > stack, not userspace. In those cases the stack can not wait for a > > > > > > > > Those are not exclusive conditions. > > > > > > > > > command from the userspace. So for example if a timer like > > > > > NoResponseTimer times out, the stack an its state machines will have > > > > > to take care of the reset quite independently. > > > > > > > > Yes. But somebody needs to handle high level errors. > > > > > > > > > If you get out of sync with an alternate mode, you reset that specific > > > > > alternate mode by exiting and re-entering it, and you do not reset the > > > > > entire PD connection, port, partner or cable. > > > > > > > > That would be the first step. If that doesn't work you will at that > > > > point either give up or use the next largest hammer. > > > > In principle you could do that in kernel space, but that implies > > > > that the kernel can detect all failures. That is unlikely. > > > > > > Any PD communication failures the kernel has to be able to detect, so > > > I guess you mean failures with the alternate modes themselves, right? > > > > > > In that case, surely exiting the mode is enough to "reset" it? When it > > > is re-entered, it has to be completely re-configured in any case. I > > > don't see how resetting the whole port or cable would guarantee that a > > > mode would become any more functional in case of failures? It will > > > however make also the other active modes to de-activate even if they > > > are functioning fine. > > > > Forget about it, I'll just add the reset attributes. I'm still not > > clear about their usefulness, but instead they will just create a small > > risk, but I can live with that. > > > > Given my experience over the last few weeks, I think the added risk > may not just be small, and I think the added benefit is questionable. > Reset handling is not well implemented in all devices, and manually > triggered resets in an unexpected state may make the situation worse. > > Can you make it optional ? I may choose not to support it to avoid > the risk. Maybe I gave up on this too hastily... I changing my mind about this, I'm not going to add them. Having them optional is not enough. It changes nothing when they are implemented. I think there is a change that we would actually end up having to remove the attributes, which would be really bad. I think we can still add them later if they are still seen as necessity later on, tough I seriously doubt it. It would not be ideal, but adding an attribute should not really break anything, right? Removing would. Thanks, -- heikki
Re: [PATCH 2/2] pci: Add PCIe driver for Rockchip Soc
On Friday, May 27, 2016 6:31:28 PM CEST Wenrui Li wrote:
> Hi,
>
> On 2016/5/27 15:13, Bharat Kumar Gogada wrote:
> >>>
> +
> +static int rockchip_pcie_rd_other_conf(struct rockchip_pcie_port *pp,
> + struct pci_bus *bus, u32 devfn,
> + int where, int size, u32 *val)
> +{
> + u32 busdev;
> +
> + busdev = PCIE_ECAM_ADDR(bus->number, PCI_SLOT(devfn),
> + PCI_FUNC(devfn), where);
> +
> + if (busdev & (size - 1)) {
> + *val = 0;
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + }
> +
> + if (size == 4) {
> + *val = readl(pp->reg_base + busdev);
> + } else if (size == 2) {
> + *val = readw(pp->reg_base + busdev);
> + } else if (size == 1) {
> + *val = readb(pp->reg_base + busdev);
> + } else {
> + *val = 0;
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + }
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> >>>
> >>> This looks like the normal ECAM operations, you could just call those.
> >>
> >> I read ECAM reference code, I found it not support ioremap config space
> >> for each bus individually on 64-bit systems. Our soc is 64-bit system,
> >> and bus0 config space base address is 0xfda0, bus1 base address is
> >> 0xf810. So I think it is not normal ECAM operations, I do not know
> >> if I have understood correctly?
> >>
> > Hi,
> >
> > I think Arnd was suggesting to use generic config read/write calls,
> > pci_generic_config_read/pci_generic_config_write
> > which does above functionality.
>
> Yeah, I seem the pci_generic_config_write use writew/writeb for byte and
> word write. but our SOC not support byte and word write in RC config
> spcace. So I redefine the the pci_ops.write
Rihgt, that bug should be documented somewhere. You can also use
the pci_generic_config_read32/pci_generic_config_write32 functions
for this.
I wonder if we should add a more general way of treating type 1
config space accesses differently, as a lot of host bridges have
similar requirements, accessing the registers in a different place,
different layout, or other constraints.
The patch below would make that very easy to do. Suggestions for
better naming welcome.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index d11cdbb8fba3..2f7dcaa63e1d 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -34,9 +34,12 @@ int pci_bus_read_config_##size \
u32 data = 0; \
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
raw_spin_lock_irqsave(&pci_lock, flags);\
- res = bus->ops->read(bus, devfn, pos, len, &data); \
+ if (bus->number == 0 && bus->ops->read0)\
+ res = bus->ops->read0(bus, devfn, pos, len, &data); \
+ else\
+ res = bus->ops->read(bus, devfn, pos, len, &data); \
*value = (type)data;\
- raw_spin_unlock_irqrestore(&pci_lock, flags); \
+ raw_spin_unlock_irqrestore(&pci_lock, flags); \
return res; \
}
@@ -48,8 +51,11 @@ int pci_bus_write_config_##size \
unsigned long flags;\
if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \
raw_spin_lock_irqsave(&pci_lock, flags);\
- res = bus->ops->write(bus, devfn, pos, len, value); \
- raw_spin_unlock_irqrestore(&pci_lock, flags); \
+ if (bus->number == 0 && bus->ops->write0) \
+ res = bus->ops->write0(bus, devfn, pos, len, value);\
+ else\
+ res = bus->ops->write(bus, devfn, pos, len, value); \
+ raw_spin_unlock_irqrestore(&pci_lock, flags); \
return res; \
}
@@ -72,7 +78,11 @@ int pci_generic_config_read(struct pci_bus *bus, unsigned
int devfn,
{
void __iomem *addr;
- addr = bus->ops->map_bus(bus, devfn, where);
+ if (bus->number == 0 && bus->ops->map_bus0)
+ addr = bus->ops->map_bus0(bus, devfn, where);
+ else
+ addr = bus->ops->map_bus(bus, devfn, where);
+
if (!addr) {
*val = ~0;
return PCIBIOS_DEVICE_NOT_FOUND;
@@ -94,7 +104,10 @@ int pci_generic_config_write(struct pci_bus *bus, unsigned
int devfn,
{
void __iomem *addr;
- addr = bus->ops->map_bus(bus, devfn, where);
+
Re: [lkp] [oom_reaper] df1e2f5663: EIP: [<81e30134>] mmput_async+0x9/0x6b SS:ESP 0068:819a5e78
On Wed 01-06-16 16:02:09, kernel test robot wrote:
>
>
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit df1e2f56632ddf17186f7036a3bd809d3aed8fd8 ("oom_reaper: close race with
> exiting task")
$ git fetch next
$ git describe next/master
next-20160601
$ git show df1e2f56632ddf17186f7036a3bd809d3aed8fd8:mm/oom_kill.c
fatal: Path 'mm/oom_kill.c' exists on disk, but not in
'df1e2f56632ddf17186f7036a3bd809d3aed8fd8'
So I am not sure which exact commit have you tested.
Anyway linux-next and Linus tree are missing a fix from Tetsuo
http://lkml.kernel.org/r/1464423365--1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
Andrew, could you merge it please?
> [ 82.815896] BUG: unable to handle kernel NULL pointer dereference at
> 0025
> [ 82.816733] IP: [<81e30134>] mmput_async+0x9/0x6b
> [ 82.817281] *pde =
> [ 82.817628] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC
> [ 82.818169] CPU: 0 PID: 13 Comm: oom_reaper Not tainted
> 4.6.0-10870-gdf1e2f5 #1
> [ 82.818973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> Debian-1.8.2-1 04/01/2014
> [ 82.819867] task: 819a2340 ti: 819a4000 task.ti: 819a4000
> [ 82.820419] EIP: 0060:[<81e30134>] EFLAGS: 00010246 CPU: 0
> [ 82.820988] EIP is at mmput_async+0x9/0x6b
> [ 82.821413] EAX: 0001 EBX: 0001 ECX: EDX:
> [ 82.822040] ESI: EDI: 819a5e9c EBP: 819a5e7c ESP: 819a5e78
> [ 82.822683] DS: 007b ES: 007b FS: GS: SS: 0068
> [ 82.823226] CR0: 80050033 CR2: 0025 CR3: 0074 CR4: 0690
> [ 82.823864] DR0: 6cd78000 DR1: DR2: DR3:
> [ 82.824511] DR6: 0ff0 DR7: 0600
> [ 82.824918] Stack:
> [ 82.825131] 0001 819a5eec 81ed1467 819a5e94 7de80301
>
> [ 82.826043] 0101 819a5edc 0246 0246 819a5eb0 81e5ca86
> 819a5edc 819a27e8
> [ 82.826968] 819a27e8 00c2 819a5edc 819a5edc
> 81e50726
> [ 82.827881] Call Trace:
> [ 82.828147] [<81ed1467>] __oom_reap_task+0x178/0x185
> [ 82.828676] [<81e5ca86>] ? put_lock_stats+0xd/0x1d
> [ 82.829234] [<81e50726>] ? preempt_count_sub+0x8b/0xce
> [ 82.829771] [<81ed18c6>] oom_reaper+0x159/0x190
> [ 82.830249] [<81e57fcf>] ? __wake_up_common+0x5f/0x5f
> [ 82.830776] [<81ed176d>] ? exit_oom_victim+0x40/0x40
> [ 82.831286] [<81e496f1>] kthread+0xad/0xb2
> [ 82.831722] [<8231e6a0>] ? _raw_spin_unlock_irq+0x61/0x6e
> [ 82.832273] [<8231eec2>] ret_from_kernel_thread+0xe/0x24
> [ 82.832824] [<81e49644>] ? __kthread_parkme+0x6e/0x6e
> [ 82.89] Code: 2c 50 68 a5 31 62 82 e8 9b af 09 00 58 5a a1 c4 85 9e 82
> 89 da e8 33 49 0d 00 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 53 e8 cc f7 4e 00
> 48 24 74 02 eb 56 89 c3 b9 ac 85 9e 82 c7 80 4c 02 00 00 e0
> [ 82.836292] EIP: [<81e30134>] mmput_async+0x9/0x6b SS:ESP 0068:819a5e78
> [ 82.837000] CR2: 0025
> [ 82.837342] ---[ end trace e937cb7742e041b3 ]---
> [ 82.837834] Kernel panic - not syncing: Fatal exception
> [ 82.838374] Kernel Offset: 0x8e0 from 0x7900 (relocation range:
> 0x7800-0x847d)
>
>
> FYI, raw QEMU command line is:
>
> qemu-system-i386 -enable-kvm -kernel
> /pkg/linux/i386-randconfig-x0-05271601/gcc-6/df1e2f56632ddf17186f7036a3bd809d3aed8fd8/vmlinuz-4.6.0-10870-gdf1e2f5
> -append 'root=/dev/ram0 user=lkp
> job=/lkp/scheduled/vm-lkp-wsx03-openwrt-i386-6/rand_boot-1-openwrt-i386.cgz-i386-randconfig-x0-05271601-df1e2f56632ddf17186f7036a3bd809d3aed8fd8-20160527-94565-1mp99it-1.yaml
> ARCH=i386 kconfig=i386-randconfig-x0-05271601 branch=linux-next/master
> commit=df1e2f56632ddf17186f7036a3bd809d3aed8fd8
> BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-05271601/gcc-6/df1e2f56632ddf17186f7036a3bd809d3aed8fd8/vmlinuz-4.6.0-10870-gdf1e2f5
> max_uptime=600
> RESULT_ROOT=/result/boot/1/vm-lkp-wsx03-openwrt-i386/openwrt-i386.cgz/i386-randconfig-x0-05271601/gcc-6/df1e2f56632ddf17186f7036a3bd809d3aed8fd8/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-lkp-wsx03-openwrt-i386-6::dhcp drbd.minor_count=8' -initrd
> /fs/sdc1/initrd-vm-lkp-wsx03-openwrt-i386-6 -m 192 -smp 1 -device
> e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog
> i6300esb -rtc base=localtime -drive
> file=/fs/sdc1/disk0-vm-lkp-wsx03-openwrt-i386-6,m
Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes
On 05/31/2016 04:42 AM, Michael Ellerman wrote: > Hi Laurent, > > Sorry no. My next branch closed for 4.7 about 3 weeks ago. > > This series has been blocked for a long time on the gdb support, but that is > now working. However it still doesn't pass its own selftests, and I had some This series was clearing all of the selftests at the time it was posted. But yes, it has some assumptions from timing and sync perspective which gets broken some times as the kernel changes. Its been bit difficult to perfect the sync requirements as we can do only some much inside the transaction once it gets started. There are scopes here to improve these selftests but not clearing them today does not really mean the patches are now functionally broken. > disagreements with the implementation - it duplicates a lot of code rather > than refactoring things. hmm, sorry, I dont remember the context here. Can you please point to the discussion in this regard ? > > I'm waiting on a patch from Cyril which will rework how the TM FP state is > handled, and that should make this series easier to implement. Can you please elaborate on this ? Has this patch been posted in the mailing list ? How does this make it easier for us to implement these ELF notes ? > > The plan is that both should go into 4.8.
Re: [PATCH v3 0/2] nvmem: remove regmap dependency
Hi Greg,
Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla:
> Hi Greg,
>
> This is v3 patchset for the leftover 2 patches for nvmem regmap
> removal series [1]. These patches are based on char-misc tree.
>
> nvmem uses regmap_raw_read/write apis to read/write data from providers,
> With recent patch 922a9f936e40 ("regmap: mmio: Convert to regmap_bus
> and fix accessor usage") nvmem providers based on regmap-mmio stopped
> working, as nvmem core was using raw accessors.
> This issue can be fixed temporarly by moving to other regmap apis,
> but we might hit same issue in future, and regmap looks like an
> overdo for nvmem. Moving to interfaces based on read/write callbacks
> from providers would be more robust.
>
> This patchset converts the nvmem core and nvmem provider drivers to
> use the new callbacks. Tested this patchset on qfprom and at24 drivers.
> Other driver are only compile tested, any testing on them would be great.
>
> Most of the patches have been applied to char-misc tree, these are the
> two patches which had some outstanding comments on mxs nvmemprovider,
> which are now fixed.
>
> Changes since v2:
> - Fixed the mxs size and dt data pointer spotted by Stefan and Fabio
>
> Changes since v1:
> - rebased mtk-efuse on top of char-misc
> - addressed concerns raised by Stefan Wahren.
>
> [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1130026.html
>
> Thanks,
> srini
>
> Srinivas Kandagatla (2):
> nvmem: mtk-efuse: remove nvmem regmap dependency
> nvmem: mxs-ocotp: remove nvmem regmap dependency
>
> drivers/nvmem/Kconfig | 1 -
> drivers/nvmem/mtk-efuse.c | 47 ++-
> drivers/nvmem/mxs-ocotp.c | 83
> +--
> 3 files changed, 54 insertions(+), 77 deletions(-)
>
any objections about this series or is it still in queue?
Stefan
[PATCH v2] livepatch: allow removal of a disabled patch
Currently we do not allow patch module to unload since there is no
method to determine if a task is still running in the patched code.
The consistency model gives us the way because when the unpatching
finishes we know that all tasks were marked as safe to call an original
function. Thus every new call to the function calls the original code
and at the same time no task can be somewhere in the patched code,
because it had to leave that code to be marked as safe.
We can safely let the patch module go after that.
Completion is used for synchronization between module removal and sysfs
infrastructure in a similar way to commit 942e443127e9 ("module: Fix
mod->mkobj.kobj potentially freed too early").
Note that we still do not allow the removal for immediate model, that is
no consistency model. The module refcount may increase in this case if
somebody disables and enables the patch several times. This should not
cause any harm.
With this change a call to try_module_get() is moved to
__klp_enable_patch from klp_register_patch to make module reference
counting symmetric (module_put() is in a patch disable path) and to
allow to take a new reference to a disabled module when being enabled.
Also all kobject_put(&patch->kobj) calls are moved outside of klp_mutex
lock protection to prevent a deadlock situation when
klp_unregister_patch is called and sysfs directories are removed. There
is no need to do the same for other kobject_put() callsites as we
currently do not have their sysfs counterparts.
Signed-off-by: Miroslav Benes
---
Based on Josh's v2 of the consistency model.
Documentation/livepatch/livepatch.txt | 29 -
include/linux/livepatch.h | 3 ++
kernel/livepatch/core.c | 80 ++-
kernel/livepatch/transition.c | 12 +-
samples/livepatch/livepatch-sample.c | 1 -
5 files changed, 72 insertions(+), 53 deletions(-)
diff --git a/Documentation/livepatch/livepatch.txt
b/Documentation/livepatch/livepatch.txt
index bee86d0fe854..a05124258a73 100644
--- a/Documentation/livepatch/livepatch.txt
+++ b/Documentation/livepatch/livepatch.txt
@@ -272,8 +272,15 @@ section "Livepatch life-cycle" below for more details
about these
two operations.
Module removal is only safe when there are no users of the underlying
-functions. The immediate consistency model is not able to detect this;
-therefore livepatch modules cannot be removed. See "Limitations" below.
+functions. The immediate consistency model is not able to detect this. The
+code just redirects the functions at the very beginning and it does not
+check if the functions are in use. In other words, it knows when the
+functions get called but it does not know when the functions return.
+Therefore it cannot be decided when the livepatch module can be safely
+removed. This is solved by a hybrid consistency model. When the system is
+transitioned to a new patch state (patched/unpatched) it is guaranteed that
+no task sleeps or runs in the old code.
+
5. Livepatch life-cycle
===
@@ -444,24 +451,6 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for
more details.
There is work in progress to remove this limitation.
- + Livepatch modules can not be removed.
-
-The current implementation just redirects the functions at the very
-beginning. It does not check if the functions are in use. In other
-words, it knows when the functions get called but it does not
-know when the functions return. Therefore it can not decide when
-the livepatch module can be safely removed.
-
-This will get most likely solved once a more complex consistency model
-is supported. The idea is that a safe state for patching should also
-mean a safe state for removing the patch.
-
-Note that the patch itself might get disabled by writing zero
-to /sys/kernel/livepatch//enabled. It causes that the new
-code will not longer get called. But it does not guarantee
-that anyone is not sleeping anywhere in the new code.
-
-
+ Livepatch works reliably only when the dynamic ftrace is located at
the very beginning of the function.
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index cd2dfd95e109..a9651c6e1b52 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -23,6 +23,7 @@
#include
#include
+#include
#if IS_ENABLED(CONFIG_LIVEPATCH)
@@ -114,6 +115,7 @@ struct klp_object {
* @list: list node for global list of registered patches
* @kobj: kobject for sysfs resources
* @enabled: the patch is enabled (but operation may be incomplete)
+ * @finish:for waiting till it is safe to remove the patch module
*/
struct klp_patch {
/* external */
@@ -125,6 +127,7 @@ struct klp_patch {
struct list_head list;
struct kobject kobj;
bool enabled;
+ struct completion finish;
};
#define klp_for_each_object(patch, obj) \
diff
Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched domain build-up
On 1 June 2016 at 02:01, Yuyang Du wrote: > On Wed, Jun 01, 2016 at 07:07:13AM +0200, Mike Galbraith wrote: >> On Tue, 2016-05-31 at 09:31 +0800, Yuyang Du wrote: >> > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote: >> > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote: >> > > > The SD_BALANCE_WAKE is irrelevant in the contexts of these two >> > > > removals, >> > > > and in addition SD_BALANCE_WAKE is not and should not be set in any >> > > > sched_domain flags so far. >> > > >> > > This Changelog doesn't make any sense... >> > >> > How? SD_BALANCE_WAKE is not in any sched_domain flags (sd->flags), even if >> > it is, it is not used anywhere, no? >> >> If the user chooses to set SD_BALANCE_WAKE in sd->flags, it is in fact >> used. It's just not turned on by default due to full balance on every >> wakeup being far too painful to do by default. > > Yup. Up to this point, we don't have any disagreement. And I don't think we > have any disagreement conceptually. What the next patch really does is: > > (1) we don't remove SD_BALANCE_WAKE as an important sched_domain flag, on > the contrary, we strengthen it. > > (2) the semantic of SD_BALANCE_WAKE is currently represented by > SD_WAKE_AFFINE, > we actually remove this representation. > > (3) regarding the semantic of SD_WAKE_AFFINE, it is really not about selecting > waker CPU or about the fast path. Conceptually, it is just saying the > waker > CPU is a valid and important candidate if SD_BALANCE_WAKE, which is just > so > obvious, so I don't think it deserves to be a separate sched_domain flag. > > (4) the outcome is, if SD_BALANCE_WAKE, we definitely will/should try waker > CPU, > and if !SD_BALANCE_WAKE, we don't try waker CPU. So nothing functional is > changed. AFAIU, there is 4 possible cases during wake up: - we don't want any balance at wake so we don't have SD_BALANCE_WAKE nor SD_WAKE_AFFINE in sched_domain->flags - we only want wake affine balance check so we only have SD_WAKE_AFFINE in sched_domain->flags - we want wake_affine and full load balance at wake so we have both SD_BALANCE_WAKE and SD_WAKE_AFFINE in sched_domain->flags - we want full load balance but want to skip wake affine fast path so we only have SD_BALANCE_WAKE in sched_domain->flags I'm not sure that we can still do only wake_affine or only full load_balance with your changes whereas these sequences are valid ones Vincent
Re: [PATCH 2/2] pci: Add PCIe driver for Rockchip Soc
On 01/06/16 03:56, Wenrui Li wrote:
> Hi:
>
> On 2016/5/27 20:25, Marc Zyngier Wrote:
>> [+Lorenzo]
>>
>> On 20/05/16 11:29, Shawn Lin wrote:
>>> RK3399 has a PCIe controller which can be used as Root Complex.
>>> This driver supports a PCIe controller as Root Complex mode.
>>>
>
> []
>
>>> +static int rockchip_pcie_init_irq_domain(struct rockchip_pcie_port *pp)
>>> +{
>>> + struct device *dev = pp->dev;
>>> + struct device_node *node = dev->of_node;
>>> + struct device_node *pcie_intc_node = of_get_next_child(node, NULL);
>>
>> That's really ugly, as it depends on the layout of your DT.
>>
>>> +
>>> + if (!pcie_intc_node) {
>>> + dev_err(dev, "No PCIe Intc node found\n");
>>> + return PTR_ERR(pcie_intc_node);
>>> + }
>>> + pp->irq_domain = irq_domain_add_linear(pcie_intc_node, 4,
>>> + &intx_domain_ops, pp);
>>
>> Why can't you just register your host controller as the interrupt
>> controller? You don't need an intermediate node for that.
>
> OK, the child node is really no need here, we will use the host
> controller as interrupt controller next patch. Thanks!
>
>>
>>> + if (!pp->irq_domain) {
>>> + dev_err(dev, "Failed to get a INTx IRQ domain\n");
>>> + return PTR_ERR(pp->irq_domain);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static irqreturn_t rockchip_pcie_subsys_irq_handler(int irq, void *arg)
>>> +{
>>> + struct rockchip_pcie_port *pp = arg;
>>> + u32 reg;
>>> + u32 sub_reg;
>>> +
>>> + reg = pcie_read(pp, PCIE_CLIENT_INT_STATUS);
>>> + if (reg & LOC_INT) {
>>> + dev_dbg(pp->dev, "local interrupt recived\n");
>>> + sub_reg = pcie_read(pp, PCIE_CORE_INT_STATUS);
>>> + if (sub_reg & PRFPE)
>>> + dev_dbg(pp->dev, "Parity error detected while reading
>>> from the PNP Receive FIFO RAM\n");
>>> +
>>> + if (sub_reg & CRFPE)
>>> + dev_dbg(pp->dev, "Parity error detected while reading
>>> from the Completion Receive FIFO RAM\n");
>>> +
>>> + if (sub_reg & RRPE)
>>> + dev_dbg(pp->dev, "Parity error detected while reading
>>> from Replay Buffer RAM\n");
>>> +
>>> + if (sub_reg & PRFO)
>>> + dev_dbg(pp->dev, "Overflow occurred in the PNP Receive
>>> FIFO\n");
>>> +
>>> + if (sub_reg & CRFO)
>>> + dev_dbg(pp->dev, "Overflow occurred in the Completion
>>> Receive FIFO\n");
>>> +
>>> + if (sub_reg & RT)
>>> + dev_dbg(pp->dev, "Replay timer timed out\n");
>>> +
>>> + if (sub_reg & RTR)
>>> + dev_dbg(pp->dev, "Replay timer rolled over after 4
>>> transmissions of the same TLP\n");
>>> +
>>> + if (sub_reg & PE)
>>> + dev_dbg(pp->dev, "Phy error detected on receive
>>> side\n");
>>> +
>>> + if (sub_reg & MTR)
>>> + dev_dbg(pp->dev, "Malformed TLP received from the
>>> link\n");
>>> +
>>> + if (sub_reg & UCR)
>>> + dev_dbg(pp->dev, "Malformed TLP received from the
>>> link\n");
>>> +
>>> + if (sub_reg & FCE)
>>> + dev_dbg(pp->dev, "An error was observed in the flow
>>> control advertisements from the other side\n");
>>> +
>>> + if (sub_reg & CT)
>>> + dev_dbg(pp->dev, "A request timed out waiting for
>>> completion\n");
>>> +
>>> + if (sub_reg & UTC)
>>> + dev_dbg(pp->dev, "Unmapped TC error\n");
>>> +
>>> + if (sub_reg & MMVC)
>>> + dev_dbg(pp->dev, "MSI mask register changes\n");
>>> +
>>> + pcie_write(pp, sub_reg, PCIE_CORE_INT_STATUS);
>>> + }
>>> +
>>> + pcie_write(pp, reg, PCIE_CLIENT_INT_STATUS);
>>> +
>>> + return IRQ_HANDLED;
>>> +}
>
> []
>
>>> +static irqreturn_t rockchip_pcie_legacy_int_handler(int irq, void *arg)
>>> +{
>>> + struct rockchip_pcie_port *pp = arg;
>>> + u32 reg;
>>> +
>>> + reg = pcie_read(pp, PCIE_CLIENT_INT_STATUS);
>>> + reg = (reg & ROCKCHIP_PCIE_RPIFR1_INTR_MASK) >>
>>> + ROCKCHIP_PCIE_RPIFR1_INTR_SHIFT;
>>> + generic_handle_irq(irq_find_mapping(pp->irq_domain, ffs(reg)));
>>
>> NAK. What you have here is a chained interrupt controller, please
>> implement it as such.
>
> Your mean is use handle_nested_irq instead of generic_handle_irq here?
No, handle_nested_irq() is for threaded interrupts. What I mean is that
you need to configure the interrupt as a cascaded interrupt, and use the
chained_irq_enter/exit helpers. As a rule of thumb, if you're calling
generic_handle_irq() in an interrupt handler, you're doing something wrong.
If you don't do that, you may end up with interrupts that are not EOIed
properly, RCU violations, and double accounting of interrupts.
> But, I found all other pci host controller drivers use this api.
I'm afraid that doesn't make it any better. Buggy code is everywhere,
and it d
Re: [RFC PATCHv2] usb: USB Type-C Connector Class
On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote: > On Tue, May 31, 2016 at 10:20:34AM -0700, Guenter Roeck wrote: > > On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote: > > > On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote: > > > > On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote: > > > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote: > > > > > > Hi Oliver, > > > > > > > > > > > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote: > > > > > > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote: > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > I'm attaching a diff instead of full v3. I'm not yet adding > > > > > > > > attributes > > > > > > > > for the reset and cable_reset. I still don't understand what is > > > > > > > > the > > > > > > > > case where the userspace would need to be able to tricker > > > > > > > > reset? Why > > > > > > > > isn't it enough for the userspace to be able to enter/exit > > > > > > > > modes? > > > > > > > > Oliver! Can you please comment? > > > > > > > > > > > > > > 1. Because we need error handling. > > > > > > >Devices crash. Cables will crash. We will get out of sync. > > > > > > >You never put yourself in a place where you cannot handle an > > > > > > >IO error. > > > > > > > 2. Because it is in the spec. We do not second guess the spec. > > > > > > >We implement it. > > > > > > > > > > > > Error conditions and crashes are the responsibility of the USB PD > > > > > > stack, not userspace. In those cases the stack can not wait for a > > > > > > > > > > Those are not exclusive conditions. > > > > > > > > > > > command from the userspace. So for example if a timer like > > > > > > NoResponseTimer times out, the stack an its state machines will have > > > > > > to take care of the reset quite independently. > > > > > > > > > > Yes. But somebody needs to handle high level errors. > > > > > > > > > > > If you get out of sync with an alternate mode, you reset that > > > > > > specific > > > > > > alternate mode by exiting and re-entering it, and you do not reset > > > > > > the > > > > > > entire PD connection, port, partner or cable. > > > > > > > > > > That would be the first step. If that doesn't work you will at that > > > > > point either give up or use the next largest hammer. > > > > > In principle you could do that in kernel space, but that implies > > > > > that the kernel can detect all failures. That is unlikely. > > > > > > > > Any PD communication failures the kernel has to be able to detect, so > > > > I guess you mean failures with the alternate modes themselves, right? > > > > > > > > In that case, surely exiting the mode is enough to "reset" it? When it > > > > is re-entered, it has to be completely re-configured in any case. I > > > > don't see how resetting the whole port or cable would guarantee that a > > > > mode would become any more functional in case of failures? It will > > > > however make also the other active modes to de-activate even if they > > > > are functioning fine. > > > > > > Forget about it, I'll just add the reset attributes. I'm still not > > > clear about their usefulness, but instead they will just create a small > > > risk, but I can live with that. > > > > > > > Given my experience over the last few weeks, I think the added risk > > may not just be small, and I think the added benefit is questionable. > > Reset handling is not well implemented in all devices, and manually > > triggered resets in an unexpected state may make the situation worse. > > > > Can you make it optional ? I may choose not to support it to avoid > > the risk. > > Maybe I gave up on this too hastily... I changing my mind about this, > I'm not going to add them. Having them optional is not enough. It > changes nothing when they are implemented. I think there is a change > that we would actually end up having to remove the attributes, which > would be really bad. > > I think we can still add them later if they are still seen as > necessity later on, tough I seriously doubt it. It would not be > ideal, but adding an attribute should not really break anything, > right? Removing would. That is true. So let's leave it out for now. I still think sane error handling will require it eventually, but that will be in the future. Regards Oliver
[PATCH 0/9] clocksource/drivers/clksrc-of: Improve error handling
The macro CLOCKSOURCE_OF_DECLARE is widely used in the timer drivers. Basically, this macro is defined to insert in a table a tuple name,function. This function is an init function called when the name matches the DT node and its signature is: typedef void (*of_init_fn_1)(struct device_node *); It does not return an error code. That results in the clocksource-probe not being able to figure out if the driver was correctly initialized or not, the different drivers to act as they were the only ones on the system (panic, instead of failing gracefully), and duplicated code for error reporting. This series initiates the logic change and centralize the error handling in the clocksource probe code. In order to do the changes little by little, a new macro was introduced: CLOCKSOURCE_OF_DECLARE_RET() It expect an init function signature: typedef int (*of_init_ret_fn_1)(struct device_node *); As soon as all drivers will have their init functions signature changed to return a value, CLOCKSOURCE_OF_DECLARE_RET will change its name back to CLOCKSOURCE_OF_DECLARE. Daniel Lezcano (9): of: Add a new macro to declare_of for one parameter function returning a value clocksource/drivers/clksrc-probe: Introduce init functions with return code clocksource/drivers/rockchip_timer: Convert init function to return error clocksource/drivers/mkt_timer: Convert init function to return error clocksource/drivers/exynos_mct: Convert init function to return error clocksource/drivers/asm9260: Convert init function to return error clocksource/drivers/cadence_ttc: Convert init function to return error clocksource/drivers/st_lpc: Convert init function to return error clocksource/drivers/dw_apb_timer: Convert init function to return error drivers/clocksource/asm9260_timer.c | 24 ++ drivers/clocksource/cadence_ttc_timer.c | 82 +++-- drivers/clocksource/clksrc-probe.c | 22 + drivers/clocksource/clksrc_st_lpc.c | 22 + drivers/clocksource/dw_apb_timer_of.c | 12 +++-- drivers/clocksource/exynos_mct.c| 36 ++- drivers/clocksource/mtk_timer.c | 10 ++-- drivers/clocksource/rockchip_timer.c| 12 +++-- include/asm-generic/vmlinux.lds.h | 2 + include/linux/clocksource.h | 3 ++ include/linux/of.h | 3 ++ 11 files changed, 151 insertions(+), 77 deletions(-) -- 1.9.1
[PATCH 7/9] clocksource/drivers/cadence_ttc: Convert init function to return error
The init functions do not return any error. They behave as the following:
- panic, thus leading to a kernel crash while another timer may work and
make the system boot up correctly
or
- print an error and let the caller unaware if the state of the system
Change that by converting the init functions to return an error conforming
to the CLOCKSOURCE_OF_RET prototype.
Proper error handling (rollback, errno value) will be changed later case
by case, thus this change just return back an error or success in the init
function.
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/cadence_ttc_timer.c | 82 +++--
1 file changed, 48 insertions(+), 34 deletions(-)
diff --git a/drivers/clocksource/cadence_ttc_timer.c
b/drivers/clocksource/cadence_ttc_timer.c
index 9be6018..aa36cbf 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -322,22 +322,22 @@ static int ttc_rate_change_clocksource_cb(struct
notifier_block *nb,
return NOTIFY_DONE;
}
-static void __init ttc_setup_clocksource(struct clk *clk, void __iomem *base,
+static int __init ttc_setup_clocksource(struct clk *clk, void __iomem *base,
u32 timer_width)
{
struct ttc_timer_clocksource *ttccs;
int err;
ttccs = kzalloc(sizeof(*ttccs), GFP_KERNEL);
- if (WARN_ON(!ttccs))
- return;
+ if (!ttccs)
+ return -ENOMEM;
ttccs->ttc.clk = clk;
err = clk_prepare_enable(ttccs->ttc.clk);
- if (WARN_ON(err)) {
+ if (err) {
kfree(ttccs);
- return;
+ return err;
}
ttccs->ttc.freq = clk_get_rate(ttccs->ttc.clk);
@@ -345,9 +345,13 @@ static void __init ttc_setup_clocksource(struct clk *clk,
void __iomem *base,
ttccs->ttc.clk_rate_change_nb.notifier_call =
ttc_rate_change_clocksource_cb;
ttccs->ttc.clk_rate_change_nb.next = NULL;
- if (clk_notifier_register(ttccs->ttc.clk,
- &ttccs->ttc.clk_rate_change_nb))
+
+ err = clk_notifier_register(ttccs->ttc.clk,
+ &ttccs->ttc.clk_rate_change_nb);
+ if (err) {
pr_warn("Unable to register clock notifier.\n");
+ return err;
+ }
ttccs->ttc.base_addr = base;
ttccs->cs.name = "ttc_clocksource";
@@ -368,14 +372,16 @@ static void __init ttc_setup_clocksource(struct clk *clk,
void __iomem *base,
ttccs->ttc.base_addr + TTC_CNT_CNTRL_OFFSET);
err = clocksource_register_hz(&ttccs->cs, ttccs->ttc.freq / PRESCALE);
- if (WARN_ON(err)) {
+ if (err) {
kfree(ttccs);
- return;
+ return err;
}
ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
sched_clock_register(ttc_sched_clock_read, timer_width,
ttccs->ttc.freq / PRESCALE);
+
+ return 0;
}
static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,
@@ -401,30 +407,35 @@ static int ttc_rate_change_clockevent_cb(struct
notifier_block *nb,
}
}
-static void __init ttc_setup_clockevent(struct clk *clk,
- void __iomem *base, u32 irq)
+static int __init ttc_setup_clockevent(struct clk *clk,
+ void __iomem *base, u32 irq)
{
struct ttc_timer_clockevent *ttcce;
int err;
ttcce = kzalloc(sizeof(*ttcce), GFP_KERNEL);
- if (WARN_ON(!ttcce))
- return;
+ if (!ttcce)
+ return -ENOMEM;
ttcce->ttc.clk = clk;
err = clk_prepare_enable(ttcce->ttc.clk);
- if (WARN_ON(err)) {
+ if (err) {
kfree(ttcce);
- return;
+ return err;
}
ttcce->ttc.clk_rate_change_nb.notifier_call =
ttc_rate_change_clockevent_cb;
ttcce->ttc.clk_rate_change_nb.next = NULL;
- if (clk_notifier_register(ttcce->ttc.clk,
- &ttcce->ttc.clk_rate_change_nb))
+
+ err = clk_notifier_register(ttcce->ttc.clk,
+ &ttcce->ttc.clk_rate_change_nb);
+ if (err) {
pr_warn("Unable to register clock notifier.\n");
+ return err;
+ }
+
ttcce->ttc.freq = clk_get_rate(ttcce->ttc.clk);
ttcce->ttc.base_addr = base;
@@ -451,13 +462,15 @@ static void __init ttc_setup_clockevent(struct clk *clk,
err = request_irq(irq, ttc_clock_event_interrupt,
IRQF_TIMER, ttcce->ce.name, ttcce);
- if (WARN_ON(err)) {
+ if (err) {
kfree(ttcce);
- return;
+ return err;
}
clockevents_config_and_register(&ttcce->ce,
ttcce->ttc.freq / PRESCA
[PATCH v2 06/27] omapfb: panel-dsi-cm: Remove legacy boot support
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 52 +++---
include/video/omap-panel-data.h| 27 ---
2 files changed, 6 insertions(+), 73 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
index 3414c2609320..a4eac6962b76 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
@@ -26,7 +26,6 @@
#include
#include
-#include
#include
/* DSI Virtual channel. Hardcoded for now. */
@@ -1127,40 +1126,6 @@ static struct omap_dss_driver dsicm_ops = {
.memory_read= dsicm_memory_read,
};
-static int dsicm_probe_pdata(struct platform_device *pdev)
-{
- const struct panel_dsicm_platform_data *pdata;
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct omap_dss_device *dssdev, *in;
-
- pdata = dev_get_platdata(&pdev->dev);
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(&pdev->dev, "failed to find video source\n");
- return -EPROBE_DEFER;
- }
- ddata->in = in;
-
- ddata->reset_gpio = pdata->reset_gpio;
-
- if (pdata->use_ext_te)
- ddata->ext_te_gpio = pdata->ext_te_gpio;
- else
- ddata->ext_te_gpio = -1;
-
- ddata->ulps_timeout = pdata->ulps_timeout;
-
- ddata->use_dsi_backlight = pdata->use_dsi_backlight;
-
- ddata->pin_config = pdata->pin_config;
-
- dssdev = &ddata->dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
static int dsicm_probe_of(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
@@ -1207,6 +1172,9 @@ static int dsicm_probe(struct platform_device *pdev)
dev_dbg(dev, "probe\n");
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
@@ -1214,17 +1182,9 @@ static int dsicm_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->pdev = pdev;
- if (dev_get_platdata(dev)) {
- r = dsicm_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = dsicm_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
- }
+ r = dsicm_probe_of(pdev);
+ if (r)
+ return r;
ddata->timings.x_res = 864;
ddata->timings.y_res = 480;
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 74486bcc754e..e7b0e889d6d0 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -105,33 +105,6 @@ struct panel_dpi_platform_data {
};
/**
- * panel_dsicm platform data
- * @name: name for this display entity
- * @source: name of the display entity used as a video source
- * @reset_gpio: gpio to reset the panel (or -1)
- * @use_ext_te: use external TE GPIO
- * @ext_te_gpio: external TE GPIO
- * @ulps_timeout: time to wait before entering ULPS, 0 = disabled (ms)
- * @use_dsi_backlight: true if panel uses DSI command to control backlight
- * @pin_config: DSI pin configuration
- */
-struct panel_dsicm_platform_data {
- const char *name;
- const char *source;
-
- int reset_gpio;
-
- bool use_ext_te;
- int ext_te_gpio;
-
- unsigned ulps_timeout;
-
- bool use_dsi_backlight;
-
- struct omap_dsi_pin_config pin_config;
-};
-
-/**
* panel_acx565akm platform data
* @name: name for this display entity
* @source: name of the display entity used as a video source
--
2.8.3
[PATCH v2 10/27] omapfb: encoder-tpd12s015: No need to include video/omap-panle-data.h
The driver does not support legacy (pdata) based probing.
Signed-off-by: Peter Ujfalusi
---
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
index 677e2545fcbe..7939157af957 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
@@ -17,7 +17,6 @@
#include
#include
-#include
struct panel_drv_data {
struct omap_dss_device dssdev;
--
2.8.3
[PATCH v2 07/27] omapfb: connector-hdmi: Remove legacy boot support
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 42 --
include/video/omap-panel-data.h| 10 --
2 files changed, 6 insertions(+), 46 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
index 6ee4129bc0c0..231b8588a59f 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
@@ -18,7 +18,6 @@
#include
#include
-#include
static const struct omap_video_timings hdmic_default_timings = {
.x_res = 640,
@@ -206,30 +205,6 @@ static struct omap_dss_driver hdmic_driver = {
.set_hdmi_infoframe = hdmic_set_infoframe,
};
-static int hdmic_probe_pdata(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct connector_hdmi_platform_data *pdata;
- struct omap_dss_device *in, *dssdev;
-
- pdata = dev_get_platdata(&pdev->dev);
-
- ddata->hpd_gpio = -ENODEV;
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(&pdev->dev, "Failed to find video source\n");
- return -EPROBE_DEFER;
- }
-
- ddata->in = in;
-
- dssdev = &ddata->dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
static int hdmic_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
@@ -261,6 +236,9 @@ static int hdmic_probe(struct platform_device *pdev)
struct omap_dss_device *dssdev;
int r;
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
@@ -268,17 +246,9 @@ static int hdmic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = &pdev->dev;
- if (dev_get_platdata(&pdev->dev)) {
- r = hdmic_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = hdmic_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
- }
+ r = hdmic_probe_of(pdev);
+ if (r)
+ return r;
if (gpio_is_valid(ddata->hpd_gpio)) {
r = devm_gpio_request_one(&pdev->dev, ddata->hpd_gpio,
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index e7b0e889d6d0..c0836b118f67 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -59,16 +59,6 @@ struct connector_dvi_platform_data {
};
/**
- * connector_hdmi platform data
- * @name: name for this display entity
- * @source: name of the display entity used as a video source
- */
-struct connector_hdmi_platform_data {
- const char *name;
- const char *source;
-};
-
-/**
* connector_atv platform data
* @name: name for this display entity
* @source: name of the display entity used as a video source
--
2.8.3
[PATCH v2 09/27] omapfb: encoder-tfp410: Remove legacy boot support
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 44 +++---
include/video/omap-panel-data.h| 14 ---
2 files changed, 6 insertions(+), 52 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
index d9048b3df495..778e3b384c2f 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
@@ -16,7 +16,6 @@
#include
#include
-#include
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -166,32 +165,6 @@ static const struct omapdss_dvi_ops tfp410_dvi_ops = {
.get_timings= tfp410_get_timings,
};
-static int tfp410_probe_pdata(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct encoder_tfp410_platform_data *pdata;
- struct omap_dss_device *dssdev, *in;
-
- pdata = dev_get_platdata(&pdev->dev);
-
- ddata->pd_gpio = pdata->power_down_gpio;
-
- ddata->data_lines = pdata->data_lines;
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(&pdev->dev, "Failed to find video source\n");
- return -ENODEV;
- }
-
- ddata->in = in;
-
- dssdev = &ddata->dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
static int tfp410_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
@@ -225,23 +198,18 @@ static int tfp410_probe(struct platform_device *pdev)
struct omap_dss_device *dssdev;
int r;
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
platform_set_drvdata(pdev, ddata);
- if (dev_get_platdata(&pdev->dev)) {
- r = tfp410_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = tfp410_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
- }
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
if (gpio_is_valid(ddata->pd_gpio)) {
r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 4d0b8832ae11..a64e9ba12b0d 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -33,20 +33,6 @@
struct omap_dss_device;
/**
- * encoder_tfp410 platform data
- * @name: name for this display entity
- * @power_down_gpio: gpio number for PD pin (or -1 if not available)
- * @data_lines: number of DPI datalines
- */
-struct encoder_tfp410_platform_data {
- const char *name;
- const char *source;
- int power_down_gpio;
- int data_lines;
-};
-
-
-/**
* connector_atv platform data
* @name: name for this display entity
* @source: name of the display entity used as a video source
--
2.8.3
[PATCH v2 18/27] drm/omap: Remove reference to pdata->default_device
The default_device is no longer used, it is a leftower from legacy. The else if (pdata->default_device) is always going to be false. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/omapdrm/dss/core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/core.c b/drivers/gpu/drm/omapdrm/dss/core.c index 7e4e5bebabbe..9cf22b30023f 100644 --- a/drivers/gpu/drm/omapdrm/dss/core.c +++ b/drivers/gpu/drm/omapdrm/dss/core.c @@ -196,8 +196,6 @@ static int __init omap_dss_probe(struct platform_device *pdev) core.default_display_name = def_disp_name; else if (pdata->default_display_name) core.default_display_name = pdata->default_display_name; - else if (pdata->default_device) - core.default_display_name = pdata->default_device->name; return 0; -- 2.8.3
[PATCH v2 26/27] [media] omap_vout: Switch to use the video/omapfb_dss.h header file
The omap_vout is only supported with omapfb. Switch the driver to use the correct header file. Signed-off-by: Peter Ujfalusi --- drivers/media/platform/omap/omap_vout.c| 2 +- drivers/media/platform/omap/omap_voutdef.h | 2 +- drivers/media/platform/omap/omap_voutlib.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c index 70c28d19ea04..22cf60991df6 100644 --- a/drivers/media/platform/omap/omap_vout.c +++ b/drivers/media/platform/omap/omap_vout.c @@ -45,7 +45,7 @@ #include #include -#include +#include #include "omap_voutlib.h" #include "omap_voutdef.h" diff --git a/drivers/media/platform/omap/omap_voutdef.h b/drivers/media/platform/omap/omap_voutdef.h index 9ccfe1f475a4..94b5d65afb19 100644 --- a/drivers/media/platform/omap/omap_voutdef.h +++ b/drivers/media/platform/omap/omap_voutdef.h @@ -11,7 +11,7 @@ #ifndef OMAP_VOUTDEF_H #define OMAP_VOUTDEF_H -#include +#include #include #define YUYV_BPP2 diff --git a/drivers/media/platform/omap/omap_voutlib.c b/drivers/media/platform/omap/omap_voutlib.c index 80b0d88f125c..58a25fdf0cce 100644 --- a/drivers/media/platform/omap/omap_voutlib.c +++ b/drivers/media/platform/omap/omap_voutlib.c @@ -26,7 +26,7 @@ #include -#include +#include #include "omap_voutlib.h" -- 2.8.3
[PATCH v2 13/27] drm/omap: connector-analog-tv: Support only Composite type in legacy boot
In legacy mode (non DT mode) support only composite connector type. The
only user for this is rx51, using composite type.
Dropping the connector_type selection via pdata will allow cleanups in
omapdss (drm vs fbdev).
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 8511c648a15c..d963b4a9cfc0 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -25,7 +25,6 @@ struct panel_drv_data {
struct omap_video_timings timings;
- enum omap_dss_venc_type connector_type;
bool invert_polarity;
};
@@ -45,10 +44,6 @@ static const struct omap_video_timings tvc_pal_timings = {
static const struct of_device_id tvc_of_match[];
-struct tvc_of_data {
- enum omap_dss_venc_type connector_type;
-};
-
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -99,7 +94,7 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in->ops.atv->set_timings(in, &ddata->timings);
if (!ddata->dev->of_node) {
- in->ops.atv->set_type(in, ddata->connector_type);
+ in->ops.atv->set_type(in, OMAP_DSS_VENC_TYPE_COMPOSITE);
in->ops.atv->invert_vid_out_polarity(in,
ddata->invert_polarity);
@@ -207,7 +202,6 @@ static int tvc_probe_pdata(struct platform_device *pdev)
ddata->in = in;
- ddata->connector_type = pdata->connector_type;
ddata->invert_polarity = pdata->invert_polarity;
dssdev = &ddata->dssdev;
--
2.8.3
[PATCH v2 17/27] ARM/video: omap2: Move omap_display_init declaration to mach-omap2/display.h
The omap_display_init() is implemented in the mach-omap2/display.c so the
declaration should have been there as well.
Change the board files to include display.h to avoid build breakage at the
same time.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-ldp.c| 1 +
arch/arm/mach-omap2/board-rx51-video.c | 1 +
arch/arm/mach-omap2/display.h | 5 +
include/video/omapdss.h| 3 ---
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d9c3ffc39329..f364a1b779f0 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -47,6 +47,7 @@
#include "hsmmc.h"
#include "control.h"
#include "common-board-devices.h"
+#include "display.h"
#define LDP_SMSC911X_CS1
#define LDP_SMSC911X_GPIO 152
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index b76f84245ad9..9866ec06a395 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -22,6 +22,7 @@
#include "soc.h"
#include "board-rx51.h"
+#include "display.h"
#include "mux.h"
diff --git a/arch/arm/mach-omap2/display.h b/arch/arm/mach-omap2/display.h
index 7375854b16c7..78f253005279 100644
--- a/arch/arm/mach-omap2/display.h
+++ b/arch/arm/mach-omap2/display.h
@@ -33,4 +33,9 @@ int omap_init_vout(void);
struct device_node * __init omapdss_find_dss_of_node(void);
+struct omap_dss_board_info;
+
+/* Init with the board info */
+int omap_display_init(struct omap_dss_board_info *board_data);
+
#endif
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 8e14ad7327c9..0c7ae93ebd76 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -330,9 +330,6 @@ struct omap_dss_board_info {
enum omapdss_version version;
};
-/* Init with the board info */
-extern int omap_display_init(struct omap_dss_board_info *board_data);
-
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
2.8.3
[PATCH v2 27/27] drm/omap: Remove the video/omapdss.h and move it's content to local header file
Move the contents of the video/omapdss.h header file to omapdrm/dss local
header file and remove the original global header. The omapfb stach is
using video/omapfb_dss.h so this change will complete the separation of the
two driver implementation.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 866 -
include/video/omapdss.h | 888 --
2 files changed, 865 insertions(+), 889 deletions(-)
delete mode 100644 include/video/omapdss.h
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index d7e7c909bbc2..9263283952b9 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -18,7 +18,871 @@
#ifndef __OMAP_DRM_DSS_H
#define __OMAP_DRM_DSS_H
-#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DISPC_IRQ_FRAMEDONE(1 << 0)
+#define DISPC_IRQ_VSYNC(1 << 1)
+#define DISPC_IRQ_EVSYNC_EVEN (1 << 2)
+#define DISPC_IRQ_EVSYNC_ODD (1 << 3)
+#define DISPC_IRQ_ACBIAS_COUNT_STAT(1 << 4)
+#define DISPC_IRQ_PROG_LINE_NUM(1 << 5)
+#define DISPC_IRQ_GFX_FIFO_UNDERFLOW (1 << 6)
+#define DISPC_IRQ_GFX_END_WIN (1 << 7)
+#define DISPC_IRQ_PAL_GAMMA_MASK (1 << 8)
+#define DISPC_IRQ_OCP_ERR (1 << 9)
+#define DISPC_IRQ_VID1_FIFO_UNDERFLOW (1 << 10)
+#define DISPC_IRQ_VID1_END_WIN (1 << 11)
+#define DISPC_IRQ_VID2_FIFO_UNDERFLOW (1 << 12)
+#define DISPC_IRQ_VID2_END_WIN (1 << 13)
+#define DISPC_IRQ_SYNC_LOST(1 << 14)
+#define DISPC_IRQ_SYNC_LOST_DIGIT (1 << 15)
+#define DISPC_IRQ_WAKEUP (1 << 16)
+#define DISPC_IRQ_SYNC_LOST2 (1 << 17)
+#define DISPC_IRQ_VSYNC2 (1 << 18)
+#define DISPC_IRQ_VID3_END_WIN (1 << 19)
+#define DISPC_IRQ_VID3_FIFO_UNDERFLOW (1 << 20)
+#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1 << 21)
+#define DISPC_IRQ_FRAMEDONE2 (1 << 22)
+#define DISPC_IRQ_FRAMEDONEWB (1 << 23)
+#define DISPC_IRQ_FRAMEDONETV (1 << 24)
+#define DISPC_IRQ_WBBUFFEROVERFLOW (1 << 25)
+#define DISPC_IRQ_WBUNCOMPLETEERROR(1 << 26)
+#define DISPC_IRQ_SYNC_LOST3 (1 << 27)
+#define DISPC_IRQ_VSYNC3 (1 << 28)
+#define DISPC_IRQ_ACBIAS_COUNT_STAT3 (1 << 29)
+#define DISPC_IRQ_FRAMEDONE3 (1 << 30)
+
+struct omap_dss_device;
+struct omap_overlay_manager;
+struct dss_lcd_mgr_config;
+struct snd_aes_iec958;
+struct snd_cea_861_aud_if;
+struct hdmi_avi_infoframe;
+
+enum omap_display_type {
+ OMAP_DISPLAY_TYPE_NONE = 0,
+ OMAP_DISPLAY_TYPE_DPI = 1 << 0,
+ OMAP_DISPLAY_TYPE_DBI = 1 << 1,
+ OMAP_DISPLAY_TYPE_SDI = 1 << 2,
+ OMAP_DISPLAY_TYPE_DSI = 1 << 3,
+ OMAP_DISPLAY_TYPE_VENC = 1 << 4,
+ OMAP_DISPLAY_TYPE_HDMI = 1 << 5,
+ OMAP_DISPLAY_TYPE_DVI = 1 << 6,
+};
+
+enum omap_plane {
+ OMAP_DSS_GFX= 0,
+ OMAP_DSS_VIDEO1 = 1,
+ OMAP_DSS_VIDEO2 = 2,
+ OMAP_DSS_VIDEO3 = 3,
+ OMAP_DSS_WB = 4,
+};
+
+enum omap_channel {
+ OMAP_DSS_CHANNEL_LCD= 0,
+ OMAP_DSS_CHANNEL_DIGIT = 1,
+ OMAP_DSS_CHANNEL_LCD2 = 2,
+ OMAP_DSS_CHANNEL_LCD3 = 3,
+ OMAP_DSS_CHANNEL_WB = 4,
+};
+
+enum omap_color_mode {
+ OMAP_DSS_COLOR_CLUT1= 1 << 0, /* BITMAP 1 */
+ OMAP_DSS_COLOR_CLUT2= 1 << 1, /* BITMAP 2 */
+ OMAP_DSS_COLOR_CLUT4= 1 << 2, /* BITMAP 4 */
+ OMAP_DSS_COLOR_CLUT8= 1 << 3, /* BITMAP 8 */
+ OMAP_DSS_COLOR_RGB12U = 1 << 4, /* RGB12, 16-bit container */
+ OMAP_DSS_COLOR_ARGB16 = 1 << 5, /* ARGB16 */
+ OMAP_DSS_COLOR_RGB16= 1 << 6, /* RGB16 */
+ OMAP_DSS_COLOR_RGB24U = 1 << 7, /* RGB24, 32-bit container */
+ OMAP_DSS_COLOR_RGB24P = 1 << 8, /* RGB24, 24-bit container */
+ OMAP_DSS_COLOR_YUV2 = 1 << 9, /* YUV2 4:2:2 co-sited */
+ OMAP_DSS_COLOR_UYVY = 1 << 10, /* UYVY 4:2:2 co-sited */
+ OMAP_DSS_COLOR_ARGB32 = 1 << 11, /* ARGB32 */
+ OMAP_DSS_COLOR_RGBA32 = 1 << 12, /* RGBA32 */
+ OMAP_DSS_COLOR_RGBX32 = 1 << 13, /* RGBx32 */
+ OMAP_DSS_COLOR_NV12 = 1 << 14, /* NV12 format: YUV 4:2:0 */
+ OMAP_DSS_COLOR_RGBA16 = 1 << 15, /* RGBA16 - */
+ OMAP_DSS_COLOR_RGBX16 = 1 << 16, /* RGBx16 - */
+ OMAP_DSS_COLOR_ARGB16_1555 = 1 << 17, /* ARGB16 - 1555 */
+ OMAP_DSS_COLOR_XRGB16_1555 = 1 << 18, /* xRGB16 - 1555 */
+};
+
+enum omap_dss_load_mode {
+ OMAP_DSS_LOAD_CLUT_AND_FRAME= 0,
+ OMAP_DSS_LOAD_CLUT_ONLY = 1,
+ OMAP_DSS_LOAD_FRAME_ONLY= 2,
+ OMAP_DSS_LOAD_CLUT_ONCE_FRAME = 3,
+};
+
+enum omap_dss_trans_key_type {
+ OMAP_DSS_COLOR_KEY_GFX_DST = 0,
+
[PATCH] fbdev: pxafb: clampval() doesn't update the variable
clampval() returns the clamped value instead of updating the variable
itself. And the driver is using it in a wrong way. Fix it.
Signed-off-by: Viresh Kumar
---
drivers/video/fbdev/pxafb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 2c0487f4f805..b1197980b9b1 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -417,12 +417,12 @@ static int pxafb_adjust_timing(struct pxafb_info *fbi,
var->yres = max_t(int, var->yres, MIN_YRES);
if (!(fbi->lccr0 & LCCR0_LCDT)) {
- clamp_val(var->hsync_len, 1, 64);
- clamp_val(var->vsync_len, 1, 64);
- clamp_val(var->left_margin, 1, 255);
- clamp_val(var->right_margin, 1, 255);
- clamp_val(var->upper_margin, 1, 255);
- clamp_val(var->lower_margin, 1, 255);
+ var->hsync_len = clamp_val(var->hsync_len, 1, 64);
+ var->vsync_len = clamp_val(var->vsync_len, 1, 64);
+ var->left_margin = clamp_val(var->left_margin, 1, 255);
+ var->right_margin = clamp_val(var->right_margin, 1, 255);
+ var->upper_margin = clamp_val(var->upper_margin, 1, 255);
+ var->lower_margin = clamp_val(var->lower_margin, 1, 255);
}
/* make sure each line is aligned on word boundary */
--
2.7.1.410.g6faf27b
Re: [lkp] [oom_reaper] df1e2f5663: EIP: [<81e30134>] mmput_async+0x9/0x6b SS:ESP 0068:819a5e78
Hi Michal, On Wed, 1 Jun 2016 10:24:58 +0200 Michal Hocko wrote: > > $ git describe next/master > next-20160601 > $ git show df1e2f56632ddf17186f7036a3bd809d3aed8fd8:mm/oom_kill.c > fatal: Path 'mm/oom_kill.c' exists on disk, but not in > 'df1e2f56632ddf17186f7036a3bd809d3aed8fd8' That's weird: $ git describe next-20160601 $ git show df1e2f56632ddf17186f7036a3bd809d3aed8fd8:mm/oom_kill.c | head -5 /* * linux/mm/oom_kill.c * * Copyright (C) 1998,2000 Rik van Riel * Thanks go out to Claus Fischer for some serious inspiration and -- Cheers, Stephen Rothwell
[PATCH] tracing: Add *iter check for NULL
From: xingzhen
3debb0a9ddb adding a "__used" to the variable in the
__trace_printk_fmt section. Sometimes it will cause
*iter to be NULL, then strcmp in lookup_format and
strcpy in hold_module_trace_bprintk_format will panic.
Signed-off-by: xingzhen
---
kernel/trace/trace_printk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
index f96f038..82ecfb5 100644
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -55,6 +55,8 @@ void hold_module_trace_bprintk_format(const char **start,
const char **end)
mutex_lock(&btrace_mutex);
for (iter = start; iter < end; iter++) {
+ if (!*iter)
+ goto err;
struct trace_bprintk_fmt *tb_fmt = lookup_format(*iter);
if (tb_fmt) {
*iter = tb_fmt->fmt;
@@ -75,6 +77,7 @@ void hold_module_trace_bprintk_format(const char **start,
const char **end)
*iter = fmt;
}
+err:
mutex_unlock(&btrace_mutex);
}
--
1.9.1
Re: [PATCH v7 04/14] perf tools: Move unwind__prepare_access from thread_new into thread__insert_map
On Tue, May 31, 2016 at 11:19:02AM +, He Kuang wrote:
> For determine the libunwind methods to use, we should get the
> 32bit/64bit information from maps of a thread. When a thread is newly
> created, the information is not prepared. This patch moves
> unwind__prepare_access() into thread__insert_map() so we can get the
> information we need from maps. Meanwhile, let thread__insert_map()
> return value and show messages on error.
>
> Signed-off-by: He Kuang
> ---
> tools/perf/util/machine.c | 10 --
> tools/perf/util/thread.c | 13 +++--
> tools/perf/util/thread.h | 2 +-
> tools/perf/util/unwind-libunwind.c | 7 +++
> 4 files changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index bdc33ce..0bd6aac 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1353,7 +1353,10 @@ int machine__process_mmap2_event(struct machine
> *machine,
> if (map == NULL)
> goto out_problem_map;
>
> - thread__insert_map(thread, map);
> + ret = thread__insert_map(thread, map);
> + if (ret)
> + pr_err("Thread insert map error\n");
> +
I think we should fail the function, not just display error
> thread__put(thread);
> map__put(map);
> return 0;
> @@ -1403,7 +1406,10 @@ int machine__process_mmap_event(struct machine
> *machine, union perf_event *event
> if (map == NULL)
> goto out_problem_map;
>
> - thread__insert_map(thread, map);
> + ret = thread__insert_map(thread, map);
> + if (ret)
> + pr_err("Thread insert map error\n");
same here
jirka
Re: [PATCH v7 06/14] perf tools: Separate local/remote libunwind config
On Tue, May 31, 2016 at 11:19:04AM +, He Kuang wrote: SNIP > ifndef NO_LIBUNWIND > + have_libunwind := >ifneq ($(feature-libunwind), 1) > msg := $(warning No libunwind found. Please install libunwind-dev[el] >= > 1.1 and/or set LIBUNWIND_DIR); > +NO_LOCAL_LIBUNWIND := 1 > + else > +have_libunwind := 1 > +CFLAGS += -DHAVE_LIBUNWIND_LOCAL_SUPPORT I dont see this defined being used.. jirka
Re: [PATCH v7 03/14] perf tools: Introducing struct unwind_libunwind_ops for local unwind
On Tue, May 31, 2016 at 11:19:01AM +, He Kuang wrote: > Currently, libunwind operations are fixed, and they are chosen > according to the host architecture. This will lead a problem that if a > thread is run as x86_32 on x86_64 machine, perf will use libunwind > methods for x86_64 to parse the callchain and get wrong result. > > This patch changes the fixed methods of libunwind operations to > thread/map related, and each thread can have indivadual libunwind > operations. Local libunwind methods are registered as default value. > > Signed-off-by: He Kuang > --- > tools/perf/util/thread.c | 6 > tools/perf/util/thread.h | 4 ++- > tools/perf/util/unwind-libunwind.c | 58 > +++--- > tools/perf/util/unwind.h | 19 + > 4 files changed, 82 insertions(+), 5 deletions(-) > > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c > index 45fcb71..95ff1b8 100644 > --- a/tools/perf/util/thread.c > +++ b/tools/perf/util/thread.c > @@ -43,6 +43,12 @@ struct thread *thread__new(pid_t pid, pid_t tid) > thread->cpu = -1; > INIT_LIST_HEAD(&thread->comm_list); > > +#ifdef HAVE_LIBUNWIND_SUPPORT > + unwind__register_ops(thread, local_unwind_libunwind_ops); > +#else > + unwind__register_ops(thread, NULL); > +#endif is it needed to register NULL? it's there by init right? jirka
Re: [PATCH v7 03/14] perf tools: Introducing struct unwind_libunwind_ops for local unwind
On Tue, May 31, 2016 at 11:19:01AM +, He Kuang wrote: > Currently, libunwind operations are fixed, and they are chosen > according to the host architecture. This will lead a problem that if a > thread is run as x86_32 on x86_64 machine, perf will use libunwind > methods for x86_64 to parse the callchain and get wrong result. > > This patch changes the fixed methods of libunwind operations to > thread/map related, and each thread can have indivadual libunwind > operations. Local libunwind methods are registered as default value. > > Signed-off-by: He Kuang > --- > tools/perf/util/thread.c | 6 > tools/perf/util/thread.h | 4 ++- > tools/perf/util/unwind-libunwind.c | 58 > +++--- > tools/perf/util/unwind.h | 19 + > 4 files changed, 82 insertions(+), 5 deletions(-) > > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c > index 45fcb71..95ff1b8 100644 > --- a/tools/perf/util/thread.c > +++ b/tools/perf/util/thread.c > @@ -43,6 +43,12 @@ struct thread *thread__new(pid_t pid, pid_t tid) > thread->cpu = -1; > INIT_LIST_HEAD(&thread->comm_list); > > +#ifdef HAVE_LIBUNWIND_SUPPORT > + unwind__register_ops(thread, local_unwind_libunwind_ops); > +#else > + unwind__register_ops(thread, NULL); > +#endif > + I think we should put unwind__register_ops call into unwind__prepare_access in this patch (like you do in patch 4) and without the #else clause this way you can keep unwind__register_ops local thanks, jirka
Re: [PATCH v7 10/14] perf tools: Check the target platform before assigning unwind methods
On Tue, May 31, 2016 at 11:19:08AM +, He Kuang wrote:
SNIP
> -int unwind__prepare_access(struct thread *thread)
> +int unwind__prepare_access(struct thread *thread, struct map *map)
> {
> - unwind__register_ops(thread, local_unwind_libunwind_ops);
> + const char *arch;
> + enum dso_type dso_type;
> + struct unwind_libunwind_ops *ops = local_unwind_libunwind_ops;
>
> - return thread->unwind_libunwind_ops->prepare_access(thread);
> + if (!thread->mg->machine->env)
> + return 0;
> +
> + dso_type = dso__type(map->dso, thread->mg->machine);
> + if (dso_type == DSO__TYPE_UNKNOWN)
> + return 0;
> +
> + if (thread->addr_space)
> + pr_debug("unwind: thread map already set, 64bit is %d,
> dso=%s\n",
> + dso_type == DSO__TYPE_64BIT, map->dso->name);
> +
> + arch = normalize_arch(thread->mg->machine->env->arch);
> + pr_debug("unwind: target platform=%s\n", arch);
> +
> + unwind__register_ops(thread, ops);
> +
> + if (thread->unwind_libunwind_ops)
> + return thread->unwind_libunwind_ops->prepare_access(thread);
> + else
> + return 0;
why do you need to check for thread->unwind_libunwind_ops != NULL?
it's all set at this point right?
jirka
Re: [PATCH v7 13/14] perf callchain: Support x86 target platform
On Tue, May 31, 2016 at 11:19:11AM +, He Kuang wrote:
SNIP
> diff --git a/tools/perf/util/unwind-libunwind.c
> b/tools/perf/util/unwind-libunwind.c
> index e183390..5774317 100644
> --- a/tools/perf/util/unwind-libunwind.c
> +++ b/tools/perf/util/unwind-libunwind.c
> @@ -5,6 +5,7 @@
> #include "arch/common.h"
>
> struct unwind_libunwind_ops __weak *local_unwind_libunwind_ops;
> +struct unwind_libunwind_ops __weak *x86_32_unwind_libunwind_ops;
>
> void unwind__register_ops(struct thread *thread,
> struct unwind_libunwind_ops *ops)
> @@ -30,7 +31,13 @@ int unwind__prepare_access(struct thread *thread, struct
> map *map)
>dso_type == DSO__TYPE_64BIT, map->dso->name);
>
> arch = normalize_arch(thread->mg->machine->env->arch);
> - pr_debug("unwind: target platform=%s\n", arch);
> +
> + if (!strcmp(arch, "x86"))
> + if (dso_type != DSO__TYPE_64BIT)
> + ops = x86_32_unwind_libunwind_ops;
> +
> + if (!ops)
> + pr_err("unwind: target platform=%s is not supported\n", arch);
how could ops become NULL in here? it starts with local_unwind_libunwind_ops
I dont think this check is needed in here
jirka
Re: [PATCH v7 13/14] perf callchain: Support x86 target platform
On Tue, May 31, 2016 at 11:19:11AM +, He Kuang wrote: SNIP > + > + ifeq ($(feature-libunwind-x86), 1) > +$(call detected,CONFIG_LIBUNWIND_X86) > +CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT > +LDFLAGS += -lunwind-x86 > +have_libunwind = 1 > + endif > + >ifneq ($(feature-libunwind), 1) > msg := $(warning No libunwind found. Please install libunwind-dev[el] >= > 1.1 and/or set LIBUNWIND_DIR); > NO_LOCAL_LIBUNWIND := 1 > diff --git a/tools/perf/util/Build b/tools/perf/util/Build > index 004fb1d..7746e09 100644 > --- a/tools/perf/util/Build > +++ b/tools/perf/util/Build > @@ -101,6 +101,7 @@ libperf-$(CONFIG_DWARF) += dwarf-aux.o > libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o > libperf-$(CONFIG_LOCAL_LIBUNWIND)+= unwind-libunwind-local.o > libperf-$(CONFIG_LIBUNWIND) += unwind-libunwind.o > +libperf-$(CONFIG_LIBUNWIND_X86) += libunwind/x86_32.o seems odd but I dont have any better idea.. let's see what others have to say ;-) thanks, jirka
Re: [PATCH v7 13/14] perf callchain: Support x86 target platform
On Tue, May 31, 2016 at 11:19:11AM +, He Kuang wrote: SNIP > diff --git a/tools/perf/util/libunwind/x86_32.c > b/tools/perf/util/libunwind/x86_32.c > new file mode 100644 > index 000..46b4111 > --- /dev/null > +++ b/tools/perf/util/libunwind/x86_32.c > @@ -0,0 +1,18 @@ > +#define REMOTE_UNWIND_LIBUNWIND > + > +#define LIBUNWIND__ARCH_REG_ID libunwind__x86_reg_id > + > +#include "unwind.h" > +#include "debug.h" > +#include "libunwind-x86.h" > +#include <../../../../arch/x86/include/uapi/asm/perf_regs.h> > + > +#undef HAVE_ARCH_X86_64_SUPPORT > +#include "../../arch/x86/util/unwind-libunwind.c" > + > +#undef NO_LIBUNWIND_DEBUG_FRAME > +#define NO_LIBUNWIND_DEBUG_FRAME so debug_frame is explicitly switched off for remote unwind? 2 things: - could we have some comments/reasonning for un/setting defines in here (and the other arch files) - could you please use the #ifndef XXX #define XXX #endif way thanks, jirka
Re: [PATCH v7 10/14] perf tools: Check the target platform before assigning unwind methods
On Tue, May 31, 2016 at 11:19:08AM +, He Kuang wrote:
SNIP
> -int unwind__prepare_access(struct thread *thread)
> +int unwind__prepare_access(struct thread *thread, struct map *map)
> {
> - unwind__register_ops(thread, local_unwind_libunwind_ops);
> + const char *arch;
> + enum dso_type dso_type;
> + struct unwind_libunwind_ops *ops = local_unwind_libunwind_ops;
>
> - return thread->unwind_libunwind_ops->prepare_access(thread);
> + if (!thread->mg->machine->env)
> + return 0;
> +
> + dso_type = dso__type(map->dso, thread->mg->machine);
> + if (dso_type == DSO__TYPE_UNKNOWN)
> + return 0;
> +
> + if (thread->addr_space)
> + pr_debug("unwind: thread map already set, 64bit is %d,
> dso=%s\n",
> + dso_type == DSO__TYPE_64BIT, map->dso->name);
should we leave once the address space is set? resseting it over
again seems like memory leak unless I'm missing something...
also this check should be probably the first thing we do in here
thanks,
jirka
> +
> + arch = normalize_arch(thread->mg->machine->env->arch);
> + pr_debug("unwind: target platform=%s\n", arch);
> +
> + unwind__register_ops(thread, ops);
> +
> + if (thread->unwind_libunwind_ops)
> + return thread->unwind_libunwind_ops->prepare_access(thread);
> + else
> + return 0;
> }
SNIP
Re: [PATCH v7 14/14] perf callchain: Support aarch64 cross-platform
On Tue, May 31, 2016 at 11:19:12AM +, He Kuang wrote: SNIP > diff --git a/tools/perf/util/Build b/tools/perf/util/Build > index 7746e09..fced833 100644 > --- a/tools/perf/util/Build > +++ b/tools/perf/util/Build > @@ -102,6 +102,7 @@ libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o > libperf-$(CONFIG_LOCAL_LIBUNWIND)+= unwind-libunwind-local.o > libperf-$(CONFIG_LIBUNWIND) += unwind-libunwind.o > libperf-$(CONFIG_LIBUNWIND_X86) += libunwind/x86_32.o > +libperf-$(CONFIG_LIBUNWIND_AARCH64) += libunwind/arm64.o > > libperf-$(CONFIG_LIBBABELTRACE) += data-convert-bt.o > > diff --git a/tools/perf/util/libunwind/arm64.c > b/tools/perf/util/libunwind/arm64.c > new file mode 100644 > index 000..99c0d42 > --- /dev/null > +++ b/tools/perf/util/libunwind/arm64.c > @@ -0,0 +1,18 @@ also please add some comments in here describing how this file works like that it setups defines to compile arch specific binary from the generic one, which is then represented by the arm64_unwind_libunwind_ops, which get assigned for each arm64 thread or something along those lines thanks, jirka > +#define REMOTE_UNWIND_LIBUNWIND > + > +#define LIBUNWIND__ARCH_REG_ID libunwind__arm64_reg_id > + > +#include "unwind.h" > +#include "debug.h" > +#include "libunwind-aarch64.h" > +#include <../../../../arch/arm64/include/uapi/asm/perf_regs.h> > +#include "../../arch/arm64/util/unwind-libunwind.c" > + > +#undef NO_LIBUNWIND_DEBUG_FRAME > +#ifdef NO_LIBUNWIND_DEBUG_FRAME_AARCH64 > +#define NO_LIBUNWIND_DEBUG_FRAME > +#endif > +#include "util/unwind-libunwind-local.c" > + > +struct unwind_libunwind_ops * > +arm64_unwind_libunwind_ops = &_unwind_libunwind_ops; SNIP
Re: [LKP] [lkp] [sched/fair] 53d3bc773e: hackbench.throughput -32.9% regression
On Wed, Jun 01, 2016 at 01:00:10PM +0800, Huang, Ying wrote: > Hi, Peter, > > Peter Zijlstra writes: > > > On Tue, May 31, 2016 at 04:34:36PM +0800, Huang, Ying wrote: > >> Hi, Ingo, > >> > >> Part of the regression has been recovered in v4.7-rc1 from -32.9% to > >> -9.8%. But there is still some regression. Is it possible for fully > >> restore it? > > > > after much searching on how you guys run hackbench... I figured > > something like: > > > > perf bench sched messaging -g 20 --thread -l 6 > > There is a reproduce file attached in the original report email, its > contents is something like below: > > 2016-05-15 08:57:02 echo performance > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor > 2016-05-15 09:06:24 /usr/bin/hackbench -g 24 --threads -l 6 > > Hope that will help you for reproduce. It did not, because I didn't have the exact same machine and its not apparent how I should modify -- if at all -- the arguments to be representative when ran on my machine. > > on my IVB-EP (2*10*2) is similar to your IVT thing. > > > > And running something like: > > > > for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ; do echo > > performance > $i ; done > > perf stat --null --repeat 10 -- perf bench sched messaging -g 20 --thread > > -l 6 | grep "seconds time elapsed" > > > > gets me: > > > > v4.6: > > > > 36.786914089 seconds time elapsed ( +- 0.49% ) > > 37.054017355 seconds time elapsed ( +- 1.05% ) > > > > > > origin/master (v4.7-rc1-ish): > > > > 34.757435264 seconds time elapsed ( +- 3.34% ) > > 35.396252515 seconds time elapsed ( +- 3.38% ) > > > > > > Which doesn't show a regression between v4.6 and HEAD; in fact it shows > > an improvement. > > Yes. For hackbench test, linus/master (v4.7-rc1+) is better than v4.6, > but it is worse than v4.6-rc7. Details is as below. That kernel was broken.. what your point?
[PATCH] futex: Add some more function commentry
From: Thomas Gleixner
Add some more comments and reformat existing ones to kernel doc style.
Reviewed-by: Darren Hart
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/futex.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index ee25f5ba4aca..800329e6076e 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -373,8 +373,12 @@ static inline int hb_waiters_pending(struct
futex_hash_bucket *hb)
#endif
}
-/*
- * We hash on the keys returned from get_futex_key (see below).
+/**
+ * hash_futex - Return the hash bucket in the global hash
+ * @key: Pointer to the futex key for which the hash is calculated
+ *
+ * We hash on the keys returned from get_futex_key (see below) and return the
+ * corresponding hash bucket in the global hash.
*/
static struct futex_hash_bucket *hash_futex(union futex_key *key)
{
@@ -384,7 +388,12 @@ static struct futex_hash_bucket *hash_futex(union
futex_key *key)
return &futex_queues[hash & (futex_hashsize - 1)];
}
-/*
+
+/**
+ * match_futex - Check whether two futex keys are equal
+ * @key1: Pointer to key1
+ * @key2: Pointer to key2
+ *
* Return 1 if two futex_keys are equal, 0 otherwise.
*/
static inline int match_futex(union futex_key *key1, union futex_key *key2)
--
2.8.1
[PATCH v2 24/27] drm/omap: Do not include video/omapdss.h directly in drivers
All drivers to include the omapdrm/dss/omapdss.h header file. This header
includes the
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 ++-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 4 ++--
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 4 ++--
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 2 +-
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 +-
drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c| 2 +-
drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 3 ++-
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 3 ++-
drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 3 ++-
drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 3 ++-
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 ++-
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 2 +-
drivers/gpu/drm/omapdrm/dss/core.c | 3 +--
drivers/gpu/drm/omapdrm/dss/dispc.c | 3 +--
drivers/gpu/drm/omapdrm/dss/dispc_coefs.c | 2 +-
drivers/gpu/drm/omapdrm/dss/display.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dpi.c | 3 +--
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c| 3 +--
drivers/gpu/drm/omapdrm/dss/dss.c | 3 +--
drivers/gpu/drm/omapdrm/dss/dss_features.c | 3 +--
drivers/gpu/drm/omapdrm/dss/hdmi.h | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi_common.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi_phy.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi_pll.c | 3 +--
drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 2 +-
drivers/gpu/drm/omapdrm/dss/output.c| 3 +--
drivers/gpu/drm/omapdrm/dss/pll.c | 3 +--
drivers/gpu/drm/omapdrm/dss/rfbi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/sdi.c | 2 +-
drivers/gpu/drm/omapdrm/dss/venc.c | 3 +--
drivers/gpu/drm/omapdrm/dss/video-pll.c | 3 +--
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
37 files changed, 44 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index d963b4a9cfc0..3485d1ecd655 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -14,9 +14,10 @@
#include
#include
-#include
#include
+#include "../dss/omapdss.h"
+
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 747f26a55e43..75f7827525cf 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -15,10 +15,10 @@
#include
#include
-
-#include
#include
+#include "../dss/omapdss.h"
+
static const struct omap_video_timings dvic_default_timings = {
.x_res = 640,
.y_res = 480,
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 225fd8d6ab31..6bac35494819 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -16,10 +16,10 @@
#include
#include
-
-#include
#include
+#include "../dss/omapdss.h"
+
static const struct omap_video_timings hdmic_default_timings = {
.x_res = 640,
.y_res = 480,
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index 8c246c213e06..a36c36d3328e 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -20,7 +20,7 @@
#include
#include
-#include
+#include "../dss/omapdss.h"
struct panel_drv_data {
struct omap_dss_device dssdev;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index 6b7d4fc3ac12..027e2365f9e0 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -15,7 +15,7 @@
#include
#include
-#include
+#include "../dss/omapdss.h"
struct panel_drv_data {
struct om
[PATCH v2 25/27] omapfb: Create new header file for omapfb DSS implementation
Copy the content of video/omapdss.h to a new (video/omapfb_dss.h) header
file and convert the omapfb drivers to use this new file.
The new header file is needed to complete the separation of omapdrm and
omapfb implementation of DSS.
Signed-off-by: Peter Ujfalusi
---
.../omap2/omapfb/displays/connector-analog-tv.c| 2 +-
.../fbdev/omap2/omapfb/displays/connector-dvi.c| 2 +-
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 2 +-
.../fbdev/omap2/omapfb/displays/encoder-opa362.c | 2 +-
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 2 +-
.../omap2/omapfb/displays/encoder-tpd12s015.c | 2 +-
.../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 2 +-
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 2 +-
.../omapfb/displays/panel-lgphilips-lb035q02.c | 2 +-
.../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 2 +-
.../omapfb/displays/panel-sharp-ls037v7dw01.c | 2 +-
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 2 +-
.../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 2 +-
.../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/apply.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/core.c| 2 +-
.../video/fbdev/omap2/omapfb/dss/dispc-compat.c| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dispc_coefs.c | 2 +-
.../video/fbdev/omap2/omapfb/dss/display-sysfs.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/display.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dpi.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dss.c | 2 +-
.../video/fbdev/omap2/omapfb/dss/dss_features.c| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi.h| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c | 2 +-
.../video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/manager.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/output.c | 2 +-
.../video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/overlay.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/pll.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/rfbi.c| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/sdi.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/venc.c| 2 +-
drivers/video/fbdev/omap2/omapfb/dss/video-pll.c | 2 +-
drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c| 2 +-
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c| 2 +-
drivers/video/fbdev/omap2/omapfb/omapfb.h | 2 +-
include/video/omapfb_dss.h | 880 +
48 files changed, 927 insertions(+), 47 deletions(-)
create mode 100644 include/video/omapfb_dss.h
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
index d963b4a9cfc0..9d78411a3bf7 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
@@ -14,7 +14,7 @@
#include
#include
-#include
+#include
#include
struct panel_drv_data {
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
index f2abbec7602a..06e1db34541e 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c
@@ -16,7 +16,7 @@
#include
-#include
+#include
static const struct omap_video_timings dvic_default_timings = {
.x_res = 640,
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
index 231b8588a59f..58d5803ede67 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
@@ -17,7 +17,7 @@
#include
-#include
+#include
static const struct omap_video_timings hdmic_default_timings = {
.x_res = 640,
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c
b/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c
index 8c246c213e06..a9a67167cc3d 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c
@@ -20,7 +20,7 @@
#include
#include
[PATCH v2 19/27] omapfb: Remove reference to pdata->default_device
The default_device is no longer used, it is a leftower from legacy. The else if (pdata->default_device) is always going to be false. Signed-off-by: Peter Ujfalusi --- drivers/video/fbdev/omap2/omapfb/dss/core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/core.c b/drivers/video/fbdev/omap2/omapfb/dss/core.c index 5a87179b7312..b9de21d3ff09 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c @@ -208,8 +208,6 @@ static int __init omap_dss_probe(struct platform_device *pdev) core.default_display_name = def_disp_name; else if (pdata->default_display_name) core.default_display_name = pdata->default_display_name; - else if (pdata->default_device) - core.default_display_name = pdata->default_device->name; register_pm_notifier(&omap_dss_pm_notif_block); -- 2.8.3
[PATCH v2 23/27] omapdss: hdmi audio: Make header file independent of video/omapdss.h
Clean up the header files regarding to hdmi audio so the omap-hdmi-audio.h
file will only need to include the platform_data/omapdss.h file.
Signed-off-by: Peter Ujfalusi
CC: Mark Brown
CC: Jyri Sarha
CC: Liam Girdwood
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 +
drivers/video/fbdev/omap2/omapfb/dss/hdmi.h | 1 +
include/sound/omap-hdmi-audio.h | 9 +++--
include/video/omapdss.h | 5 -
sound/soc/omap/omap-hdmi-audio.c| 1 -
5 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index 53616b02b613..c32a21a26054 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "dss.h"
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
index 53616b02b613..c32a21a26054 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "dss.h"
diff --git a/include/sound/omap-hdmi-audio.h b/include/sound/omap-hdmi-audio.h
index afdb416898e0..1df2ff61a4dd 100644
--- a/include/sound/omap-hdmi-audio.h
+++ b/include/sound/omap-hdmi-audio.h
@@ -16,11 +16,16 @@
*
*/
-#include
-
#ifndef __OMAP_HDMI_AUDIO_H__
#define __OMAP_HDMI_AUDIO_H__
+#include
+
+struct omap_dss_audio {
+ struct snd_aes_iec958 *iec;
+ struct snd_cea_861_aud_if *cea;
+};
+
struct omap_hdmi_audio_ops {
int (*audio_startup)(struct device *dev,
void (*abort_cb)(struct device *dev));
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 53ada70cf23c..b25e2eab4b48 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -168,11 +168,6 @@ enum omap_dss_display_state {
OMAP_DSS_DISPLAY_ACTIVE,
};
-struct omap_dss_audio {
- struct snd_aes_iec958 *iec;
- struct snd_cea_861_aud_if *cea;
-};
-
enum omap_dss_rotation_type {
OMAP_DSS_ROT_DMA= 1 << 0,
OMAP_DSS_ROT_VRFB = 1 << 1,
diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c
index 64425d352962..888133f9e65d 100644
--- a/sound/soc/omap/omap-hdmi-audio.c
+++ b/sound/soc/omap/omap-hdmi-audio.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#define DRV_NAME "omap-hdmi-audio"
--
2.8.3
[PATCH v2 20/27] video: omapdss: Remove unused members from struct omap_dss_board_info
The num_devices, **devices and *default_device is leftover from the past.
They can be removed as they are no used.
Signed-off-by: Peter Ujfalusi
---
include/video/omapdss.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 0c7ae93ebd76..a43859a0a398 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -320,9 +320,6 @@ enum omapdss_version {
/* Board specific data */
struct omap_dss_board_info {
- int num_devices;
- struct omap_dss_device **devices;
- struct omap_dss_device *default_device;
const char *default_display_name;
int (*dsi_enable_pads)(int dsi_id, unsigned lane_mask);
void (*dsi_disable_pads)(int dsi_id, unsigned lane_mask);
--
2.8.3
[PATCH v2 22/27] ARM: OMAP2: Use the platform_data header for omapdss
Instead of the full omapdss internal header, include only the platform_data header. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-omap2/board-ldp.c| 2 +- arch/arm/mach-omap2/board-rx51-video.c | 2 +- arch/arm/mach-omap2/display.c | 2 +- arch/arm/mach-omap2/dss-common.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index f364a1b779f0..390795b334c3 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -39,7 +39,7 @@ #include "gpmc.h" #include "gpmc-smsc911x.h" -#include +#include #include #include "board-flash.h" diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c index 9866ec06a395..180c6aa633bd 100644 --- a/arch/arm/mach-omap2/board-rx51-video.c +++ b/arch/arm/mach-omap2/board-rx51-video.c @@ -15,7 +15,7 @@ #include #include #include -#include +#include #include #include diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 6ab13d18c636..70b3eaf085e4 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -29,7 +29,7 @@ #include #include -#include +#include #include "omap_hwmod.h" #include "omap_device.h" #include "omap-pm.h" diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c index ea2be0f5953b..1d583bc0b1a9 100644 --- a/arch/arm/mach-omap2/dss-common.c +++ b/arch/arm/mach-omap2/dss-common.c @@ -27,7 +27,7 @@ #include #include -#include +#include #include #include "soc.h" -- 2.8.3
Re: [PATCH -v2 19/33] locking,powerpc: Implement atomic{,64}_fetch_{add,sub,and,or,xor}{,_relaxed,_acquire,_release}()
On Wed, Jun 01, 2016 at 02:10:45PM +0800, Boqun Feng wrote: > On Wed, Jun 01, 2016 at 11:11:38AM +0800, Boqun Feng wrote: > > Looks like I missed this one in v1, it should be > > > > return res; Indeed. > > because the primitives will return the values before modified by the > > operations. > > > > FWIW, I tested on ppc with ATOMIC64_SELFTEST=y for the following branch: Thanks, I'll add a tested-by tag with your name on ;-)
