The PWM core is now able to initialize the PWM period. Use it and if it is not
configured, use the supplied pwm_period_ns.
Signed-off-by: Alexandre Belloni
---
drivers/leds/leds-pwm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-pwm.c
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-pxa/hx4700.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index 0788a1f171fe..c66ad4edc5e3 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 1bf61dad9a35..ca82b1e2ebab
FYI, bi_rw tracks more than WRITE or READ...
On Sat, Apr 12, 2014 at 12:22 AM, Jianyu Zhan wrote:
> Print the r/w direction string instead of internal values.
>
> Signed-off-by: Jianyu Zhan
> ---
> block/blk-core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f27e1ec90b5e..54c135a5b4f7 100644
---
The PWM core is now able to initialize the PWM period from platform_data. Use it
and if it is not configured, use the supplied pwm_period_ns.
Signed-off-by: Alexandre Belloni
---
drivers/video/backlight/pwm_bl.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
> -Original Message-
> From: Quentin Casasnovas [mailto:quentin.casasno...@oracle.com]
> Sent: Tuesday, March 18, 2014 12:17 PM
> To: David Airlie
> Cc: linux-kernel@vger.kernel.org; Quentin Casasnovas;
> sta...@vger.kernel.org; Koenig, Christian; Deucher, Alexander
> Subject: [PATCH]
Now that ipu_dc_disable_channel correctly waits for the channel to finish,
we can reorder the enable/disable order to first stop the DC and DI and
only then disable the IDMAC. Enabling is done the other way around: IDMAC
first, then DC, then DI.
This avoids an issue where sometimes the channel
Disabling the DMFC module while there is still data in the FIFOs could
cause the "new frame before end of frame" error state when the DMFC is
enabled again.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 25 +++--
1 file changed, 23
Repeatedly enabling and disabling the display currently can lead to a state
in which the IPU doesn't produce a valid signal anymore because we disable
IPU submodules before they can finish their interaction.
This series reorders the enable/disable sequence so that we first wait for the
DC/DP to
This allows to request the DC related interrupts.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 1 +
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 19 +--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 22 ++
drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
Wait for the DC Frame Complete or DP Sync Flow End interrupts
before disabling DC channels.
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Moved disable_irq() out of dc_irq_handler()
---
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 +++--
1 file changed, 50
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 ++
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 14 --
drivers/staging/imx-drm/ipuv3-crtc.c| 8 ++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
index 6980fa1..d90f82a 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dp.c
+++
The former has to be done before disabling the DMFC, the latter has to be
done afterwards. Otherwise the DMFC FIFOs never get cleared properly.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 +
drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 68
On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
>
> Zitat von Benjamin Herrenschmidt :
>
> >On Sun, 2014-04-13 at 21:22 +0200, Stefani Seibold wrote:
> >>When executing a kexec kernel on a PowerPC board the new started kernel
> >>will not find already enumerated USB devices
Currently, there's no way to find out which super_blocks are
associated with a given kernfs_root. Let's implement it - the planned
inotify extension to kernfs_notify() needs it.
Make kernfs_super_info point back to the super_block and chain it at
kernfs_root->supers.
Signed-off-by: Tejun Heo
On Wed, 2 Apr 2014 11:47:31 +0300 Dan Carpenter
wrote:
> Imagine you have a user controlled variable at the end of a struct which
> is allocated at the end of a page. The strlen() could read beyond the
> mapped memory and cause an oops.
Well, it's hard to conceive of a situation where
On Mon, Apr 14, 2014 at 05:21:32PM +0200, Philipp Zabel wrote:
> Wait for the DC Frame Complete or DP Sync Flow End interrupts
> before disabling DC channels.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71
> +++--
> 1 file
On Mon, Apr 14, 2014 at 05:36:58PM -0400, Tejun Heo wrote:
> The patchset is on top of cgroup/for-3.15 01a971406177 ("cgroup: Use
> RCU_INIT_POINTER(x, NULL) in cgroup.c") and also available in the
> following git branch.
Oops, obviously, the patchset is on top of
v3.15-rc1 c9eaa447e77e ("Linux
Hello,
This is v2 of cgroup.populated patchset changes from v1[L] are,
* Rebased on top of v3.15-rc1
* Patch description updated for the third patch as per Serge.
(inotify folks, can you please review the second patch which hooks up
kernfs_notify() with fsnotify? It works but directly
cgroup users often need a way to determine when a cgroup's
subhierarchy becomes empty so that it can be cleaned up. cgroup
currently provides release_agent for it; unfortunately, this mechanism
is riddled with issues.
* It delivers events by forking and execing a userland binary
specified as
kernfs_notify() is used to indicate either new data is available or
the content of a file has changed. It currently only triggers poll
which may not be the most convenient to monitor especially when there
are a lot to monitor. Let's hook it up to fsnotify too so that the
events can be monitored
In the planned default unified hierarchy, controllers may get
dynamically attached to and detached from a cgroup and a cgroup may
not have csses for all the controllers associated with the hierarchy.
When a cgroup doesn't have its own css for a given controller, the css
of the nearest ancestor
Hello,
This is v2 of the unified hierarchy patchset. Changes from v1[1] are,
* Rebased on top of v3.15-rc1
* Interface file "cgroup.controllers" which was only available in the
root is now available in all cgroups. This allows, e.g., a
sub-manager in charge of a subtree to tell which
On the default unified hierarchy, a cgroup may be associated with
csses of its ancestors, which means that a css of a given cgroup may
be associated with css_sets of descendant cgroups. This means that we
can't walk all tasks associated with a css by iterating the css_sets
associated with the
To implement the unified hierarchy behavior, we'll need to be able to
determine the associated cgroup on the default hierarchy from css_set.
Let's add css_set->dfl_cgrp so that it can be accessed conveniently
and efficiently.
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 3 +++
Now that effective css handling has been added and iterators updated
accordingly, it's safe to allow cgroup creation in the default
hierarchy. Unblock cgroup creation in the default hierarchy.
As the default hierarchy will implement explicit enabling and
disabling of controllers on each cgroup,
After a css finishes offlining, offline_css() mistakenly performs
RCU_INIT_POINTER(css->cgroup->subsys[ss->id], css) which just sets the
cgroup->subsys[] pointer to the current value. The intention was to
clear it after offline is complete, not reassign the same value.
Update it to assign NULL
css_next_child() walks the children of the specified css. It does
this by finding the next cgroup and then returning the requested css.
On the default unified hierarchy, a cgroup may not have a css
associated with it even if the hierarchy has the subsystem enabled.
This patch updates
On Mon, Apr 14, 2014 at 09:51:51PM +0100, Mark Brown wrote:
> On Sat, Apr 12, 2014 at 11:48:35AM -0700, Jane Wan wrote:
> > Make FSL eSPI properties configurable through device tree. The
> > configurable parameters include CSnBEF and CSnAFT in ESPI_SPMODEn
> > registers (n=0,1,2,3), and whether
Because the default root couldn't have any non-root csses attached to
it, rebinding away from it was always allowed; however, the default
hierarchy will soon host the unified hierarchy and have non-root csses
so the rebind restrictions need to be updated accordingly.
Instead of special casing
This patch reorganizes css_task_iter so that adding effective css
support is easier.
* s/->cset_link/->cset_pos/ and s/->task/->task_pos/ for consistency
* ->origin_css is used to determine whether the iteration reached the
last css_set. Replace it with explicit ->cset_head so that
Unified hierarchy implementation would require re-migrating tasks onto
the same cgroup on the default hierarchy to reflect updated effective
csses. Update cgroup_migrate_prepare_dst() so that it accepts NULL as
the destination cgrp. When NULL is specified, the destination is
considered to be the
On Sun, Mar 30, 2014 at 03:34:15PM +0200, Mathias Krause wrote:
> If we've registered a notifier in pda_power_probe() we must deregister
> it in pda_power_remove() to not let it work on stale data like, e.g.,
> the charger timer.
>
> Cc: Felipe Balbi
> Cc: Anton Vorontsov
> Signed-off-by:
cgroup is switching away from multiple hierarchies and will use one
unified default hierarchy where controllers can be dynamically enabled
and disabled per subtree. The default hierarchy will serve as the
unified hierarchy to which all controllers are attached and a css on
the default hierarchy
944196278d3d ("cgroup: move ->subsys_mask from cgroupfs_root to
cgroup") moved ->subsys_mask from cgroup_root to cgroup to prepare for
the unified hierarhcy; however, it turns out that carrying the
subsys_mask of the children in the parent, instead of itself, is a lot
more natural. This patch
Currently, css_task_iter iterates tasks associated with a css by
visiting each css_set associated with the owning cgroup and walking
tasks of each of them. This works fine for !unified hierarchies as
each cgroup has its own css for each associated subsystem on the
hierarchy; however, on the
On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
I'm afraid to say
On Thu, Mar 27, 2014 at 10:40:49PM -0400, Tejun Heo wrote:
> The patchset is on top of cgroup/for-3.15 01a971406177 ("cgroup: Use
> RCU_INIT_POINTER(x, NULL) in cgroup.c") and also available in the
> following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
On Wed, Apr 09, 2014 at 11:07:29AM -0400, Tejun Heo wrote:
> This patchset is on top of "cgroup: implement unified hierarchy"
> patchset[1] and availalbe in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-populated
Branch renamed to
On Tue, 1 Apr 2014 11:19:05 -0400 Prarit Bhargava wrote:
> When a module is built into the kernel the module_init() function becomes
> an initcall. Sometimes debugging through dynamic debug can help,
> however, debugging built in kernel modules is typically done by changing
> the .config,
On Mon, 2014-04-14 at 15:22 -0400, David Miller wrote:
>
> You still need to make similar transformation to ip_local_out() as mentioned
> above.
I was trying to cook a not too invasive patch.
Changing ip_local_out() means changing dst_output() / nf_hook() and
hundred of call sites.
Unless I
Okay, v2 of the series, now with moar TLB flushing!
-Kees
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
This introduces CONFIG_DEBUG_RODATA, making kernel text and rodata
read-only. Additionally, this splits rodata from text so that rodata can
also be NX, which may lead to wasted memory when aligning to SECTION_SIZE.
The read-only areas are made writable during ftrace updates. Additional
work is
Adds CONFIG_ARM_KERNMEM_PERMS to separate the kernel memory regions
into section-sized areas that can have different permisions. Performs
the NX permission changes during free_initmem, so that init memory can be
reclaimed.
This uses section size instead of PMD size to reduce memory lost to
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/arm_big_little.c | 18 ++
1 file changed, 10 insertions(+), 8
On Sat, Mar 08, 2014 at 11:55:29AM +0800, Axel Lin wrote:
> The is_enabled implementation is wrong in some cases:
> e.g. for pbias_mmc_omap5: enable_mask is : BIT(27) | BIT(25) | BIT(26)
> However, pbias_regulator_enable() only sets BIT(27) | BIT(26) bits.
> So is_enabled callback will always
On Thu, Apr 03, 2014 at 07:04:00AM +, li.xi...@freescale.com wrote:
> > Generally just not
> > mentioning regmap is better for a binding definition, the binding should
> > be usable by all OSs and not just Linux.
> How about move the endianness OF parsing to the driver/of/ ?
> Is this will
The cpufreq core supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/sh/clk/core.c | 19 +--
1 file changed, 5 insertions(+), 14
On Mon, Apr 14, 2014 at 10:09:08AM +0200, Krzysztof Kozlowski wrote:
> Add documentation for new property for controlling (enable/disable) some
> of the S2MPS14 regulators by GPIO.
Applied, thanks.
signature.asc
Description: Digital signature
On Mon, Apr 14, 2014 at 10:09:07AM +0200, Krzysztof Kozlowski wrote:
> Add support for external control over GPIO for LDO10, LDO11 and LDO12
> S2MPS14 regulators. External control can be turned on by writing 0x0 to
> control register which in case of other regulators is used for disabling
> them.
Hi Greg,
On Mon, 14 Apr 2014 12:11:43 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote:
> > Configuring kernels from scratch has become an incredibly long and
> > tedious task. The reason is that the number of drivers and options has
> > exploded in the past
On Mon, Apr 14, 2014 at 10:09:06AM +0200, Krzysztof Kozlowski wrote:
> Refactor code for parsing DTS to increase a little code readability. The
> behaviour should not change.
Applied, thanks.
signature.asc
Description: Digital signature
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
arch/mips/loongson/lemote-2f/clock.c | 15 +--
1 file changed, 5 insertions(+), 10
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
Please note that I was no able to compile test this patch due to
lack of cross compiler.
On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote:
> - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
> + - samsung,ext-control-gpios: (optional) GPIO specifier for one
> GPIO controlling this regulator (enable/disable); This is
>
The cpufreq core supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
Please note that I was no able to compile test this patch due to
lack of cross
The cpufreq core supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/thermal/cpu_cooling.c | 33 +
1 file changed, 13
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
Please note that I was no able to compile test this patch due to
lack of cross compiler.
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
arch/arm/mach-davinci/da850.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/mfd/db8500-prcmu.c | 18 --
1 file changed, 8 insertions(+), 10
The cpufreq core supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/s3c64xx-cpufreq.c | 15 +--
1
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/powernow-k6.c | 13 +++--
1 file changed, 7 insertions(+), 6
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/longhaul.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
The cpufreq core supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/s3c2416-cpufreq.c | 40
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/exynos5440-cpufreq.c | 30 +++---
1 file changed, 15
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/elanfreq.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/dbx500-cpufreq.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/exynos-cpufreq.c | 14 +++---
1 file changed, 7 insertions(+), 7
On Tue, Apr 08, 2014 at 01:19:01PM -0700, Kees Cook wrote:
> > To prevent any stale entries being used indefinitely, perhaps the all
> > CPU TLB flush can be inserted into
> > ftrace_arch_code_modify_post_process(), which is called after the
> > stop_machine() and which is where x86 for example
On Mon, Apr 14, 2014 at 5:49 PM, Alex Thorlton wrote:
> On Mon, Apr 14, 2014 at 12:15:01PM +0200, Michael Kerrisk wrote:
>> Alex,
>>
>> Your commit a0715cc22601e8830ace98366c0c2bd8da52af52 added the prctl()
>> PR_SET_THP_DISABLE and PR_GET_THP_DISABLE flags.
>>
>> The text below attempts to
The cpufreq core supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_stats.c | 22 --
1 file changed, 8
Most cpufreq drivers need to iterate over the cpufreq_frequency_table
for various tasks.
This patch introduces two macros which can be used for iteration over
cpufreq_frequency_table keeping a common coding style across drivers:
- cpufreq_for_each_entry: iterate over each entry of the table
-
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/acpi-cpufreq.c | 10 +-
1 file changed, 5 insertions(+), 5
Hi all,
This patch set introduces two freq_table helper macros which
can be used for iteration over cpufreq_frequency_table and
makes the necessary changes to cpufreq core and drivers that
use such an iteration procedure.
The motivation was a usage of common procedure to iterate over
On Thu, Apr 03, 2014 at 05:26:57AM +, li.xi...@freescale.com wrote:
> > Actually, if we're going to be doing this for all devices then we
> > probably need to namespace the properties too. Not sure what to do for
> > a prefix though. One for the DT folks.
> How about using one prefix
On Mon, Apr 14, 2014 at 03:08:05PM +0200, Boris BREZILLON wrote:
> SMBus is a subset of the I2C protocol, oftenly used to access registers on
> external devices.
This is basically fine. However...
> + switch (ctx->transfer_type) {
> + case REGMAP_SMBUS_BYTE_TRANSFER:
> +
On April 14, 2014 8:02:29 AM GMT+01:00, Jonathan Cameron
wrote:
>
>
>On April 14, 2014 2:51:22 AM GMT+01:00, Srinivas Pandruvada
> wrote:
>>
>>On 04/12/2014 09:52 AM, Jonathan Cameron wrote:
>>> On 09/04/14 01:56, Srinivas Pandruvada wrote:
This callback is introduced to overcome some
When the thingm driver registers an instance of LED class, it creates a
"play" sysfs attribute for this blink(1) specific feature.
Since this feature is not specific to the RGB chip but to the HID device
itself, let's remove this attribute from the LED instance and only
implement what is useful
This patchset introduces the support of the blink(1) mk2 device, after a
refactoring of the thingm driver. It removes non-standard sysfs attributes and
uses work queues to fix the usage of triggers with this device.
Vivien Didelot (4):
HID: (thingm) remove the "play" sysfs attribute
HID:
As for the "play" sysfs attribute, remove this other non-standard
attribute, so the driver only implements what is required to switch the
LED on and off. Thus, a fade time won't be ideal for some fast-changing
triggers.
Signed-off-by: Vivien Didelot
---
smp_read_barrier_depends() can be used if there is data dependency between
the readers - i.e. if the read operation after the barrier uses address
that was obtained from the read operation before the barrier.
In this file, there is only control dependency, no data dependecy, so the
use of
The blink(1) mk2 is a new version of the blink(1) USB RGB LED. The new
generation has 2 individually-controllable RGB chips.
This patch adds support for this device to the thingm driver, which
registers 3 new standard LED class instances for the second RGB chip.
Note that the 'n' (set) command
This patch refactors the way the thingm driver registers a blink(1) LED.
In order to make the driver simpler and more standard, drop the "rgb"
sysfs attribute and create one instance of LED class per RGB channel.
Actually, the name of the LED class instance registered for a blink(1)
device is
Commit-ID: e179f6914152eca9b338e7d8445684062f560c55
Gitweb: http://git.kernel.org/tip/e179f6914152eca9b338e7d8445684062f560c55
Author: K. Y. Srinivasan
AuthorDate: Mon, 14 Apr 2014 11:43:49 -0700
Committer: H. Peter Anvin
CommitDate: Mon, 14 Apr 2014 11:49:55 -0700
x86, irq, pic:
On Sat, Apr 12, 2014 at 11:48:36AM -0700, Jane Wan wrote:
> Make FSL eSPI CSnBEF and CSnAFT in ESPI_SPMODEn registers (n=0,1,2,3)
> configurable through device tree. FSL eSPI driver hardcodes them to 0.
> Some device requires different value.
What do these do?
> Allow FSL eSPI driver
On Sat, Apr 12, 2014 at 11:48:35AM -0700, Jane Wan wrote:
> Make FSL eSPI properties configurable through device tree. The
> configurable parameters include CSnBEF and CSnAFT in ESPI_SPMODEn
> registers (n=0,1,2,3), and whether to send all received data to user.
Don't send cover letters for
MyungJoo/Kyungmin,
Bump. Can we accept this patch please?
-Saravana
On 04/10/2014 07:54 PM, Saravana Kannan wrote:
Some devices use freq_table instead of OPP. For those devices, the
available_frequencies file shows up empty. Fix that by using freq_table to
generate the available_frequencies
On Mon, Apr 14, 2014 at 09:11:25AM +0100, Glyn Normington wrote:
> Johannes/Michal
>
> What are your thoughts on this matter? Do you see this as a valid
> requirement?
As Tejun said, memory cgroups *do* respond to internal pressure and
enter targetted reclaim before invoking the OOM killer. So
On Fri, Apr 11, 2014 at 06:30:09PM +0800, Nicolin Chen wrote:
> By doing this, the driver can drop around 50 lines and become neater.
Applied, thanks.
signature.asc
Description: Digital signature
On Wed, Apr 02, 2014 at 06:10:19PM +0800, Nicolin Chen wrote:
> -- clock-names : Must include the "sai" entry.
> +- clock-names : Must include the "bus" for register access and "mclk1"
> "mclk2"
> + "mclk3" for bit clock and frame clock providing.
This breaks compatibilty with old DTs - it
On Wed, Apr 02, 2014 at 06:10:20PM +0800, Nicolin Chen wrote:
> Since we added fours clock to the DT binding, we should update the current
> SAI dts/dtsi so as not to break their functions.
This doesn't apply against v3.15-rc1, can you please check and resend?
signature.asc
Description: Digital
On Fri, Apr 11, 2014 at 10:10:00PM +0800, Nicolin Chen wrote:
> + /* Check if the opposite FRDE is also disabled */
> + if (!(tx ? rcsr & FSL_SAI_CSR_FRDE : tcsr & FSL_SAI_CSR_FRDE)) {
I've applied this since it's a fix but this is *not* a triumph of
legibility, the
On Mon, Apr 14, 2014 at 1:24 PM, David Miller wrote:
> From: Andy Lutomirski
> Date: Mon, 14 Apr 2014 13:13:45 -0700
>
>> I think this description is wrong. (unsigned long *) >args[1] is
>> the right location, at least on 32-bit little-endian architectures.
>
> It absolutely is not.
Huh? It's
From: Andy Lutomirski
Date: Mon, 14 Apr 2014 13:13:45 -0700
> I think this description is wrong. (unsigned long *) >args[1] is
> the right location, at least on 32-bit little-endian architectures.
It absolutely is not.
The thing is a u64, and we must respect that type in a completely
portable
Applied to percpu/for-3.15-fixes with slightly updated commit message.
Thanks.
--- 8< ---
>From 5a838c3b60e3a36ade764cf7751b8f17d7c9c2da Mon Sep 17 00:00:00 2001
From: Jianyu Zhan
Date: Mon, 14 Apr 2014 13:47:40 +0800
pcpu_chunk_struct_size = sizeof(struct pcpu_chunk) +
git tree from yesterday afternoon sometime, before Linus cut .15-rc1
kernel BUG at mm/filemap.c:1347!
invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: 8021q garp bridge stp dlci snd_seq_dummy tun fuse rfcomm
ipt_ULOG nfnetlink llc2 af_key scsi_transport_iscsi hidp can_raw
This MIC virtual bus driver takes the responsibility of creating all
the virtual devices connected to the PCIe device on the host and the
platform device on the card. The MIC bus hardware operations provide
a way to abstract certain hardware details from the base physical devices.
Examples of
201 - 300 of 2040 matches
Mail list logo
