From: Cai Zhiyong
Date: Sat, 14 May 2016 14:13:30 +0800
Subject: [PATCH] devfreq: fix double call put_device
1295 */
1296 void device_unregister(struct device *dev)
1297 {
1298 pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
1299 device_del(dev);
From: Cai Zhiyong
Date: Sat, 14 May 2016 14:13:30 +0800
Subject: [PATCH] devfreq: fix double call put_device
1295 */
1296 void device_unregister(struct device *dev)
1297 {
1298 pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
1299 device_del(dev);
1300
Hello all:
Shall I send patch v2 for it? (if really need, please let me know, and I
shall try).
Default, I shall continue to try to find and send another patches for mm
in "include/linux/*.h".
Thanks.
On 5/3/16 00:38, Chen Gang wrote:
> On 5/3/16 00:23, Chen Gang wrote:
>> On 5/2/16 23:35,
Hello all:
Shall I send patch v2 for it? (if really need, please let me know, and I
shall try).
Default, I shall continue to try to find and send another patches for mm
in "include/linux/*.h".
Thanks.
On 5/3/16 00:38, Chen Gang wrote:
> On 5/3/16 00:23, Chen Gang wrote:
>> On 5/2/16 23:35,
On May 8, 2016 7:05 PM, "Stas Sergeev" wrote:
>
> 09.05.2016 04:32, Andy Lutomirski пишет:
>
>> On May 7, 2016 7:38 AM, "Stas Sergeev" wrote:
>>>
>>> 03.05.2016 20:31, Andy Lutomirski пишет:
>>>
If a signal stack is set up with SS_AUTODISARM, then the kernel
On May 8, 2016 7:05 PM, "Stas Sergeev" wrote:
>
> 09.05.2016 04:32, Andy Lutomirski пишет:
>
>> On May 7, 2016 7:38 AM, "Stas Sergeev" wrote:
>>>
>>> 03.05.2016 20:31, Andy Lutomirski пишет:
>>>
If a signal stack is set up with SS_AUTODISARM, then the kernel
inherently avoids
On May 1, 2016 at 9:51 AM, Lnus Torvalds wrote:
> On Sun, May 1, 2016 at 2:43 AM, George Spelvin wrote:
>> * If you feel ambitious, add a 32-bit CONFIG_ARCH_HAS_SLOW_MULTIPLIER
>> exception path.
> Let's make that a separate worry, and just fix hash_64() first.
>
> In
On May 1, 2016 at 9:51 AM, Lnus Torvalds wrote:
> On Sun, May 1, 2016 at 2:43 AM, George Spelvin wrote:
>> * If you feel ambitious, add a 32-bit CONFIG_ARCH_HAS_SLOW_MULTIPLIER
>> exception path.
> Let's make that a separate worry, and just fix hash_64() first.
>
> In particular, that means
Hi Doug,
On 2016年05月14日 04:10, Doug Anderson wrote:
Hi,
On Fri, May 13, 2016 at 11:42 AM, Brian Norris wrote:
From: Xing Zheng
There was a typo, swapping 'c' <--> 'g'.
Signed-off-by: Xing Zheng
Signed-off-by:
Hi Doug,
On 2016年05月14日 04:10, Doug Anderson wrote:
Hi,
On Fri, May 13, 2016 at 11:42 AM, Brian Norris wrote:
From: Xing Zheng
There was a typo, swapping 'c' <--> 'g'.
Signed-off-by: Xing Zheng
Signed-off-by: Brian Norris
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file
Instead of comparing the thread's euid to GLOBAL_ROOT_UID, use
capabilities to check the additional privileges required to migrate
processes between cgroups. In addition, add further permissions to
cgroup namespaces where:
* Both tasks are in the same cgroup namespace; and
* The current task has
Instead of comparing the thread's euid to GLOBAL_ROOT_UID, use
capabilities to check the additional privileges required to migrate
processes between cgroups. In addition, add further permissions to
cgroup namespaces where:
* Both tasks are in the same cgroup namespace; and
* The current task has
This is an updated (and rewritten) version of v3 of this patchset[1].
The main difference is that I changed how we the "allow management" is
implemented. Rather than just chmod-ing the cgroup directory (which
everyone agreed was quite an odd way of doing it),
unshare(CLONE_NEWCGROUP) will create
Allow unprivileged processes to control subtrees of their associated
processes, a necessary feature if a rootless container wishes to take
advantage of cgroups for its own processes.
As cgroups are hierarchical, having the ability to set limits in a
subtree does not preclude the ability to modify
This is an updated (and rewritten) version of v3 of this patchset[1].
The main difference is that I changed how we the "allow management" is
implemented. Rather than just chmod-ing the cgroup directory (which
everyone agreed was quite an odd way of doing it),
unshare(CLONE_NEWCGROUP) will create
Allow unprivileged processes to control subtrees of their associated
processes, a necessary feature if a rootless container wishes to take
advantage of cgroups for its own processes.
As cgroups are hierarchical, having the ability to set limits in a
subtree does not preclude the ability to modify
On 5/13/2016 6:53 AM, Arnd Bergmann wrote:
> A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
> MIPS system unfortunately broke big-endian operation on PowerPC
> APM82181 as reported by Christian Lamparter, and likely other
> systems.
>
> It actually introduced multiple issues:
HI Andrew,
On Fri, May 13, 2016 at 11:13 PM, Andrew Lunn wrote:
> Hi Harini
>
> Is this backward compatible? Will devices using the old binding still
> work?
It isn't right now.
I will have to assign the bus read/write functions conditionally in order to
do that - I'll see if I
On 5/13/2016 6:53 AM, Arnd Bergmann wrote:
> A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
> MIPS system unfortunately broke big-endian operation on PowerPC
> APM82181 as reported by Christian Lamparter, and likely other
> systems.
>
> It actually introduced multiple issues:
HI Andrew,
On Fri, May 13, 2016 at 11:13 PM, Andrew Lunn wrote:
> Hi Harini
>
> Is this backward compatible? Will devices using the old binding still
> work?
It isn't right now.
I will have to assign the bus read/write functions conditionally in order to
do that - I'll see if I can make it
On (05/14/16 08:08), Minchan Kim wrote:
[..]
> Fortunately, Andrew isn't pick up this patch yet so I want to replace
> it to below suggested by Sergey which is better.
[..]
>
> + atomic64_inc(>stats.writestall);
looks good to me. thanks!
-ss
On (05/14/16 08:08), Minchan Kim wrote:
[..]
> Fortunately, Andrew isn't pick up this patch yet so I want to replace
> it to below suggested by Sergey which is better.
[..]
>
> + atomic64_inc(>stats.writestall);
looks good to me. thanks!
-ss
Hello Minchan,
On (05/14/16 08:05), Minchan Kim wrote:
[..]
> > recompress:
> > compress
> > handle = zs_malloc FAST PATH
> >
> > if (!handle) {
> > release stream
> > handle = zs_malloc SLOW PATH
> >
> > << my patch accounts SLOW PATH here >>
> >
Hello Minchan,
On (05/14/16 08:05), Minchan Kim wrote:
[..]
> > recompress:
> > compress
> > handle = zs_malloc FAST PATH
> >
> > if (!handle) {
> > release stream
> > handle = zs_malloc SLOW PATH
> >
> > << my patch accounts SLOW PATH here >>
> >
From: Andi Kleen
Add declarations for the events needed for TopDown to the
Intel big core CPUs starting with Sandy Bridge. We need
to report different values if HyperThreading is on or off.
The only thing this patch does is to export some events
in sysfs.
TopDown level 1
From: Andi Kleen
Add declarations for the events needed for TopDown to the
Intel big core CPUs starting with Sandy Bridge. We need
to report different values if HyperThreading is on or off.
The only thing this patch does is to export some events
in sysfs.
TopDown level 1 uses a set of
From: Andi Kleen
Add topdown event declarations to Silvermont / Airmont.
These cores do not support the full Top Down metrics, but an useful
subset (FrontendBound, Retiring, Backend Bound/Bad Speculation).
The perf stat tool automatically handles the missing events
and
Note to reviewers: includes both tools and kernel patches.
The kernel patches are at the beginning.
[v2: Address review feedback.
Metrics are now always printed, but colored when crossing threshold.
--topdown implies --metric-only.
Various smaller fixes, see individual patches]
[v3: Add
From: Andi Kleen
Add topdown event declarations to Silvermont / Airmont.
These cores do not support the full Top Down metrics, but an useful
subset (FrontendBound, Retiring, Backend Bound/Bad Speculation).
The perf stat tool automatically handles the missing events
and combines the available
Note to reviewers: includes both tools and kernel patches.
The kernel patches are at the beginning.
[v2: Address review feedback.
Metrics are now always printed, but colored when crossing threshold.
--topdown implies --metric-only.
Various smaller fixes, see individual patches]
[v3: Add
From: Andi Kleen
For SMT specific workarounds it is useful to know if SMT is active
on any online CPU in the system. This currently requires a loop
over all online CPUs.
Add a global variable that is updated with the maximum number
of smt threads on any CPU on
From: Andi Kleen
Add basic plumbing for TopDown in perf stat
Add a new --topdown options to enable events.
When --topdown is specified set up events for all topdown
events supported by the kernel.
Add topdown-* as a special case to the event parser, as is
needed for all
From: Andi Kleen
When the scaling factor is a full integer don't display fractional
digits. This avoids unnecessary .00 output for topdown metrics
with scale factors.
v2: Remove redundant check.
Signed-off-by: Andi Kleen
---
From: Andi Kleen
Now that we have topology_max_smt_threads() use it
to detect the HT workarounds for older CPUs.
v2: Use topology_max_smt_threads()
Signed-off-by: Andi Kleen
---
arch/x86/events/intel/core.c | 6 ++
1 file changed, 2
From: Andi Kleen
Add basic plumbing for TopDown in perf stat
Add a new --topdown options to enable events.
When --topdown is specified set up events for all topdown
events supported by the kernel.
Add topdown-* as a special case to the event parser, as is
needed for all events containing -.
From: Andi Kleen
When the scaling factor is a full integer don't display fractional
digits. This avoids unnecessary .00 output for topdown metrics
with scale factors.
v2: Remove redundant check.
Signed-off-by: Andi Kleen
---
tools/perf/builtin-stat.c | 7 ---
1 file changed, 4
From: Andi Kleen
Now that we have topology_max_smt_threads() use it
to detect the HT workarounds for older CPUs.
v2: Use topology_max_smt_threads()
Signed-off-by: Andi Kleen
---
arch/x86/events/intel/core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Andi Kleen
For SMT specific workarounds it is useful to know if SMT is active
on any online CPU in the system. This currently requires a loop
over all online CPUs.
Add a global variable that is updated with the maximum number
of smt threads on any CPU on online/offline, and use it for
From: Andi Kleen
Add a way to show different sysfs events attributes depending on
HyperThreading is on or off. This is difficult to determine
early at boot, so we just do it dynamically when the sysfs
attribute is read.
v2:
Compute HT status only once in CPU online/offline
From: Andi Kleen
Implement the TopDown formulas in perf stat. The topdown basic metrics
reported by the kernel are collected, and the formulas are computed
and output as normal metrics.
See the kernel commit exporting the events for details on the used
metrics.
v2: Always
From: Andi Kleen
Add a way to show different sysfs events attributes depending on
HyperThreading is on or off. This is difficult to determine
early at boot, so we just do it dynamically when the sysfs
attribute is read.
v2:
Compute HT status only once in CPU online/offline hooks.
v3: Use
From: Andi Kleen
Implement the TopDown formulas in perf stat. The topdown basic metrics
reported by the kernel are collected, and the formulas are computed
and output as normal metrics.
See the kernel commit exporting the events for details on the used
metrics.
v2: Always print all metrics,
Hi David,
Vivien Didelot writes:
> Now that the bridge code defers the switchdev port state setting, there
> is no need to defer the port STP state change within the mv88e6xxx code.
> Thus get rid of the driver's bridge work code.
>
> This also fixes a race
Hi David,
Vivien Didelot writes:
> Now that the bridge code defers the switchdev port state setting, there
> is no need to defer the port STP state change within the mv88e6xxx code.
> Thus get rid of the driver's bridge work code.
>
> This also fixes a race condition where the DSA layer assumes
On Fri, 2016-03-18 at 22:26 +0100, Richard Cochran wrote:
> When performing a suspend operation, the kernel brings all of the
> non-boot CPUs offline, calling the hot plug notifiers with the flag,
> CPU_TASKS_FROZEN, set in the action code. Similarly, during resume,
> the CPUs are brought back
On Fri, 2016-03-18 at 22:26 +0100, Richard Cochran wrote:
> When performing a suspend operation, the kernel brings all of the
> non-boot CPUs offline, calling the hot plug notifiers with the flag,
> CPU_TASKS_FROZEN, set in the action code. Similarly, during resume,
> the CPUs are brought back
Now that the bridge code defers the switchdev port state setting, there
is no need to defer the port STP state change within the mv88e6xxx code.
Thus get rid of the driver's bridge work code.
This also fixes a race condition where the DSA layer assumes that the
bridge code already set the
Now that the bridge code defers the switchdev port state setting, there
is no need to defer the port STP state change within the mv88e6xxx code.
Thus get rid of the driver's bridge work code.
This also fixes a race condition where the DSA layer assumes that the
bridge code already set the
This is useful for running the script from somewhere besides the root of
the source tree.
Signed-off-by: Martin Kelly
---
scripts/kconfig/merge_config.sh | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/merge_config.sh
This is useful for running the script from somewhere besides the root of
the source tree.
Signed-off-by: Martin Kelly
---
scripts/kconfig/merge_config.sh | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/merge_config.sh
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> From: Kumar Gala
>
> Add an implementation of the SCM interface that works on ARM64 SoCs. This
> is used by things like determine if we have HDCP support or not on the
> system.
>
> Signed-off-by: Kumar Gala
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> From: Kumar Gala
>
> Add an implementation of the SCM interface that works on ARM64 SoCs. This
> is used by things like determine if we have HDCP support or not on the
> system.
>
> Signed-off-by: Kumar Gala
> Signed-off-by: Andy Gross
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch converts the Qualcomm SCM driver to use the streaming DMA APIs
> for communication buffers.
>
> Signed-off-by: Andy Gross
> ---
> drivers/firmware/qcom_scm-32.c | 189
>
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch converts the Qualcomm SCM driver to use the streaming DMA APIs
> for communication buffers.
>
> Signed-off-by: Andy Gross
> ---
> drivers/firmware/qcom_scm-32.c | 189
> +++--
>
On Fri, May 13, 2016 at 11:56:12PM +0300, Sergei Shtylyov wrote:
> On 05/13/2016 11:44 PM, Andrew Lunn wrote:
>
> >>>Another issue is that on some boards we have one reset line tied to
> >>>multiple PHYs.How do we prevent multiple resets being taking place when
> >>>each of
> >>>the PHYs are
On Fri, May 13, 2016 at 11:56:12PM +0300, Sergei Shtylyov wrote:
> On 05/13/2016 11:44 PM, Andrew Lunn wrote:
>
> >>>Another issue is that on some boards we have one reset line tied to
> >>>multiple PHYs.How do we prevent multiple resets being taking place when
> >>>each of
> >>>the PHYs are
The following patch[1] adds a new "cpumode" to the perf_sample
structure that gets initialised as events are read from the data
event file.
With the advent of HW tracers and more specifically the decoding of
the traces they generate, function perf_session__deliver_synth_event()
gets called
The following patch[1] adds a new "cpumode" to the perf_sample
structure that gets initialised as events are read from the data
event file.
With the advent of HW tracers and more specifically the decoding of
the traces they generate, function perf_session__deliver_synth_event()
gets called
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch changes the cold_set_boot_addr function to use atomic SCM
> calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to
> support the two arguments going to the smc call. Using atomic removes
> the need for memory allocation
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch changes the cold_set_boot_addr function to use atomic SCM
> calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to
> support the two arguments going to the smc call. Using atomic removes
> the need for memory allocation
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch converts the Qualcomm SCM firmware driver into a platform
> driver.
>
> Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
Regards,
Bjorn
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch converts the Qualcomm SCM firmware driver into a platform
> driver.
>
> Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
Regards,
Bjorn
Tadeusz -
David updated the keys-asym-keyctl branch, and this patch set won't build
any more.
On Thu, 5 May 2016, Tadeusz Struk wrote:
diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
index e00793d..f486b6d 100644
--- a/crypto/algif_akcipher.c
+++ b/crypto/algif_akcipher.c
Tadeusz -
David updated the keys-asym-keyctl branch, and this patch set won't build
any more.
On Thu, 5 May 2016, Tadeusz Struk wrote:
diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
index e00793d..f486b6d 100644
--- a/crypto/algif_akcipher.c
+++ b/crypto/algif_akcipher.c
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch adds the device tree support for the Qualcomm SCM firmware.
>
> Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
Regards,
Bjorn
On Thu 12 May 20:46 PDT 2016, Andy Gross wrote:
> This patch adds the device tree support for the Qualcomm SCM firmware.
>
> Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
Regards,
Bjorn
On Fri, May 13, 2016 at 10:03:58PM +0900, Sergey Senozhatsky wrote:
> debug_stat sysfs is read-only and represents various debugging
> data that zram developers may need. This file is not meant to be
> used by anyone else: its content is not documented and will change
> any time w/o any notice.
On Fri, May 13, 2016 at 10:03:58PM +0900, Sergey Senozhatsky wrote:
> debug_stat sysfs is read-only and represents various debugging
> data that zram developers may need. This file is not meant to be
> used by anyone else: its content is not documented and will change
> any time w/o any notice.
Hello Sergey,
On Fri, May 13, 2016 at 05:06:43PM +0900, Sergey Senozhatsky wrote:
> On (05/13/16 16:20), Minchan Kim wrote:
> > > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram,
> > > > > struct bio_vec *bvec, u32 index,
> > > > >
Hello Sergey,
On Fri, May 13, 2016 at 05:06:43PM +0900, Sergey Senozhatsky wrote:
> On (05/13/16 16:20), Minchan Kim wrote:
> > > > > @@ -737,12 +737,12 @@ static int zram_bvec_write(struct zram *zram,
> > > > > struct bio_vec *bvec, u32 index,
> > > > >
From: Rafael J. Wysocki
The design of the cpufreq governor API is not very straightforward,
as struct cpufreq_governor provides only one callback to be invoked
from different code paths for different purposes. The purpose it is
invoked for is determined by its second
There is invalid error code check of register_chrdev() in megaraid_init().
register_chrdev() returns negative code in case of error,
as a result current code can try to unregister_chrdev() with error code
instead of major that may lead to unregistering somebody else's chardev.
Found by Linux
There is invalid error code check of register_chrdev() in megaraid_init().
register_chrdev() returns negative code in case of error,
as a result current code can try to unregister_chrdev() with error code
instead of major that may lead to unregistering somebody else's chardev.
Found by Linux
From: Rafael J. Wysocki
The design of the cpufreq governor API is not very straightforward,
as struct cpufreq_governor provides only one callback to be invoked
from different code paths for different purposes. The purpose it is
invoked for is determined by its second "event" argument, causing
From: Rafael J. Wysocki
None of the cpufreq governors currently in the tree will ever fail
an invocation of the ->governor() callback with the event argument
equal to CPUFREQ_GOV_LIMITS (unless invoked with incorrect arguments
which doesn't matter anyway) and had it
From: Rafael J. Wysocki
The performance and powersave cpufreq governors handle the
CPUFREQ_GOV_START event in the same way as CPUFREQ_GOV_LIMITS.
However, the cpufreq core always invokes cpufreq_governor() with the
event argument equal to CPUFREQ_GOV_LIMITS right
From: Rafael J. Wysocki
The cpufreq_governor() routine is used by the cpufreq core to invoke
the current governor's ->governor() callback with appropriate arguments
and do some housekeeping related to that. Unfortunately, the way it
mixes different governor events in
From: Rafael J. Wysocki
None of the cpufreq governors currently in the tree will ever fail
an invocation of the ->governor() callback with the event argument
equal to CPUFREQ_GOV_LIMITS (unless invoked with incorrect arguments
which doesn't matter anyway) and had it ever failed, the result of
it
From: Rafael J. Wysocki
The performance and powersave cpufreq governors handle the
CPUFREQ_GOV_START event in the same way as CPUFREQ_GOV_LIMITS.
However, the cpufreq core always invokes cpufreq_governor() with the
event argument equal to CPUFREQ_GOV_LIMITS right after invoking it with
event
From: Rafael J. Wysocki
The cpufreq_governor() routine is used by the cpufreq core to invoke
the current governor's ->governor() callback with appropriate arguments
and do some housekeeping related to that. Unfortunately, the way it
mixes different governor events in one code path makes it
From: Rafael J. Wysocki
It is not necessary to check the governor's max_transition_latency
attribute every time cpufreq_governor() runs, so check it only if
the event argument is CPUFREQ_GOV_POLICY_INIT.
Signed-off-by: Rafael J. Wysocki
On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote:
> On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote:
> > Hi,
> >
> > This patch set adds low/high limit for blk-throttle cgroup. The interface is
> > io.low and io.high.
> >
> > low limit implements best effort bandwidth/iops
From: Rafael J. Wysocki
It is not necessary to check the governor's max_transition_latency
attribute every time cpufreq_governor() runs, so check it only if
the event argument is CPUFREQ_GOV_POLICY_INIT.
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/cpufreq.c | 25
On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote:
> On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote:
> > Hi,
> >
> > This patch set adds low/high limit for blk-throttle cgroup. The interface is
> > io.low and io.high.
> >
> > low limit implements best effort bandwidth/iops
Hi,
This series is on top of the current linux-next witn the following two patches
applied:
https://patchwork.kernel.org/patch/9080801/
https://patchwork.kernel.org/patch/9080791/
It cleans up a few things and then reworks the governor API to get rid of
governor events and use callbacks
Hi,
This series is on top of the current linux-next witn the following two patches
applied:
https://patchwork.kernel.org/patch/9080801/
https://patchwork.kernel.org/patch/9080791/
It cleans up a few things and then reworks the governor API to get rid of
governor events and use callbacks
Hi,
On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote:
> Rockchip's rk3399 evaluation board has eMMC. Let's enable the
> newly-added nodes.
>
> Signed-off-by: Brian Norris
> ---
> v4:
>
> * alphabetize references
>
> v3:
>
> * no change
>
Hi,
On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote:
> Rockchip's rk3399 evaluation board has eMMC. Let's enable the
> newly-added nodes.
>
> Signed-off-by: Brian Norris
> ---
> v4:
>
> * alphabetize references
>
> v3:
>
> * no change
>
> v2:
>
> * better commit description
>
>
Hi,
On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote:
> Per the examples in
> Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the
> grf node to be a simple-mfd in order to properly enumerate child devices
> like our eMMC PHY.
>
> Signed-off-by:
Hi,
On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote:
> Per the examples in
> Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the
> grf node to be a simple-mfd in order to properly enumerate child devices
> like our eMMC PHY.
>
> Signed-off-by: Brian Norris
> ---
> v4:
>
On 13 May 2016 at 17:19, Bjorn Andersson wrote:
> On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:
>
>> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> [..]
>> > I assume we could have the QRTR go through Andy and arm-soc, with
>> > David's approval and this
On 13 May 2016 at 17:19, Bjorn Andersson wrote:
> On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:
>
>> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> [..]
>> > I assume we could have the QRTR go through Andy and arm-soc, with
>> > David's approval and this fix squashed in. But we're
On 5/13/2016 7:58 AM, Peter Zijlstra wrote:
On Thu, May 12, 2016 at 11:39:47PM -0700, Vikram Mulukutla wrote:
Hi,
I came across a piece of engineering code that looked like:
preempt_disable();
/* --cut, lots of code-- */
preempt_enable_no_resched();
put_user()
preempt_disable();
(If you wish
On 5/13/2016 7:58 AM, Peter Zijlstra wrote:
On Thu, May 12, 2016 at 11:39:47PM -0700, Vikram Mulukutla wrote:
Hi,
I came across a piece of engineering code that looked like:
preempt_disable();
/* --cut, lots of code-- */
preempt_enable_no_resched();
put_user()
preempt_disable();
(If you wish
On Thu 12 May 17:52 PDT 2016, Andrew Duggan wrote:
> On 05/11/2016 08:05 PM, Bjorn Andersson wrote:
> >On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote:
> >
> >>Hi Bjorn,
> >>
> >>On 05/10/2016 08:49 AM, Bjorn Andersson wrote:
> >[..]
> >>>So either we duplicate the regulator support in spi/i2c
On Thu 12 May 17:52 PDT 2016, Andrew Duggan wrote:
> On 05/11/2016 08:05 PM, Bjorn Andersson wrote:
> >On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote:
> >
> >>Hi Bjorn,
> >>
> >>On 05/10/2016 08:49 AM, Bjorn Andersson wrote:
> >[..]
> >>>So either we duplicate the regulator support in spi/i2c
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> Some of the spacing was wrong (spaces instead of tabs), and due to
> longer entries added later, the columns weren't aligned. Let's get
> everything consistent.
>
> Signed-off-by: Brian Norris
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> Some of the spacing was wrong (spaces instead of tabs), and due to
> longer entries added later, the columns weren't aligned. Let's get
> everything consistent.
>
> Signed-off-by: Brian Norris
> ---
> drivers/phy/phy-rockchip-emmc.c |
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> The output tap delay controls helps maintain the hold requirements for
> eMMC. The exact value is dependent on the SoC and other factors, though
> it isn't really an exact science. But the default of 0 is not
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> The output tap delay controls helps maintain the hold requirements for
> eMMC. The exact value is dependent on the SoC and other factors, though
> it isn't really an exact science. But the default of 0 is not very good,
> as it doesn't
1 - 100 of 1122 matches
Mail list logo