devm_input_allocate_device already sets the parent device to be that
passed to it, we also set this manually in arizona_extcon_probe. This
patch removes the redundant set from arizona_extcon_probe.
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |1 -
1 files changed, 0 ins
From: Nikesh Oswal
Use extcon cable API instead of state API as it is much more
idiomatic.
Signed-off-by: Nikesh Oswal
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/extcon/extcon
29.05.2014 19:33, Nikita Yushchenko пишет:
> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>> I don't know how linux usb subsystem should behave against such
>>> "half-existing" hardware. Perhaps hanging is not the best idea...
>>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>
On 5/15/2014 12:23 PM, Arnd Bergmann wrote:
On Thursday 15 May 2014 12:01:32 Murali Karicheri wrote:
+static int
+keystone_pcie_fault(unsigned long addr, unsigned int fsr,
+ struct pt_regs *regs)
+{
+ unsigned long instr = *(unsigned long *) instruction_pointer(regs);
+
+
The higher levels of impedance have a higher minimum value than the
first level. As the same value was used for all levels, higher impedances
were reported with a very low level of accuracy. This patch applies the
approriate lower threshold for each level.
Signed-off-by: Charles Keepax
---
drive
On Thu, May 29, 2014 at 12:26 AM, Rusty Russell wrote:
> Results (x86-64, Minchan's .config):
>
> gcc 4.8.2: virtio_blk: stack used = 392
> gcc 4.6.4: virtio_blk: stack used = 528
I wonder if that's just random luck (although 35% more stack use seems
to be bigger than "random" - that's quite a bi
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8960-cdp.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8660-surf.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Add GSBI node and configuration of GSBI controller
Signed-off-by:
On Thu, May 29, 2014 at 10:14:35AM -0500, Kumar Gala wrote:
>
> On Apr 24, 2014, at 11:31 AM, Andy Gross wrote:
>
> > This patch removes direct access of the GSBI registers. GSBI configuration
> > should be done through the GSBI driver directly.
> >
> > Signed-off-by: Andy Gross
> > ---
> > d
Add basic APQ8064 SoC include device tree and support for basic booting on
the IFC6410 board. Also, keep dtb build list and qcom_dt_match in sorted
order.
Signed-off-by: Kumar Gala
---
v2:
* Fix gsbi controller reg address
arch/arm/boot/dts/Makefile | 8 +-
arch/arm/boot/dts/
First posted to drbd mailing list on 2/6 with no reply. It hasn't
happened since, but once is enough to mean something is wrong
somewhere.
I did a resize of all the underlying LVMs and that proceeded very
nicely since drbd automatically recognized the new sizes and
resize2fs automatically fi
On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
> On 15 May 2014 19:57, Arnd Bergmann wrote:
> > On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:
...
> >> +struct mbox_controller {
> >> + struct device *dev;
> >> + struct mbox_chan_ops *ops;
> >> + struct mbox_chan *cha
On Thu, 29 May 2014, Nikita Yushchenko wrote:
> 29.05.2014 18:42, One Thousand Gnomes пишет:
> >> I don't know how linux usb subsystem should behave against such
> >> "half-existing" hardware. Perhaps hanging is not the best idea...
> >> but maybe it should be fixed elsewhere, e.g. by masking non-
On Thu, May 29, 2014 at 08:10:57AM -0700, Linus Torvalds wrote:
> If so, though, that brings up two questions:
>
> (a) do we really want to be that aggressive? Can we ever traverse
> _past_ the point we're actually trying to shrink in
> shrink_dcache_parent()?
Caller of shrink_dcache_parent() wo
29.05.2014 19:44, Alan Stern пишет:
> On Thu, 29 May 2014, Nikita Yushchenko wrote:
>
>> 29.05.2014 18:42, One Thousand Gnomes пишет:
I don't know how linux usb subsystem should behave against such
"half-existing" hardware. Perhaps hanging is not the best idea...
but maybe it should
On Thu, May 29, 2014 at 02:26:55PM +0530, Satish Patel wrote:
>
>
> On 5/29/2014 12:14 AM, Greg KH wrote:
> >On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:
> >>+/**
> >>+ * struct sc_phy - The basic smart card phy structure
> >>+ *
> >>+ * @dev: phy device
> >>+ * @pdata: pointer t
On Thu, May 29, 2014 at 08:47:31AM -0500, Rob Herring wrote:
> On Thu, May 29, 2014 at 3:34 AM, Satish Patel wrote:
> >
> >
> > On 5/29/2014 12:23 AM, Greg KH wrote:
> >>
> >> On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:
> >>>
> >>> SmartCard controller uses this interface to comm
On Thu, May 29, 2014 at 02:07:59PM +0530, Satish Patel wrote:
>
>
> On 5/29/2014 12:14 AM, Greg KH wrote:
> >On Wed, May 28, 2014 at 02:27:14PM +0530, Satish Patel wrote:
> >>TDA8026 is a SmartCard PHY from NXP.
> >>
> >>The PHY interfaces with the main processor over the
> >>I2C interface and ac
On Thu, May 29, 2014 at 03:35:37PM +0530, Satish Patel wrote:
> >>+enum usim_card_mode {
> >>+ USIM_CARD_MODE_ASYNC = 0, /* asynchronous mode */
> >>+ USIM_CARD_MODE_SYNC_TYPE1, /* synchronous mode: Type 1 */
> >>+ USIM_CARD_MODE_SYNC_TYPE2, /* synchronous mode: Ty
On Thu, May 29, 2014 at 09:24:08AM +0200, Fabian Frederick wrote:
> Add ODEBUG: prefix to pr_fmt
>
> Cc: Josh Triplett
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Reviewed-by: Josh Triplett
> lib/debugobjects.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
On Thu, May 29, 2014 at 09:22:58AM +0200, Fabian Frederick wrote:
> Convert all printk to pr_foo() except KERN_DEBUG
> (see Documentation/CodingStyle Chapter 13)
>
> Cc: Josh Triplett
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Reviewed-by: Josh Triplett
> lib/debugobjects.c | 12
On Thu, May 29, 2014 at 09:25:32AM +0200, Fabian Frederick wrote:
> Direct conversion of one KERN_DEBUG message without DEBUG definition
> (suggested by Josh Triplett)
>
> That message will now be disabled by default.
> (see Documentation/CodingStyle Chapter 13)
>
> Cc: Josh Triplett
> Cc: Andre
On 05/23/2014 05:41 PM, Kevin Hilman wrote:
> By default, add some padding to the DT blobs to facilitate later
> patching.
>
> An example need for DTB patching is the need to modifiy the command
> line on platforms where ATAGS are not (or cannot) be used to pass the
> commandline. For example, we
On 05/23/2014 02:36 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.
Signed-off-by: Kumar Gala
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100
On May 29, 2014, at 10:18 AM, Liviu Dudau wrote:
> On Thu, May 29, 2014 at 10:03:54AM -0500, Kumar Gala wrote:
>>
>> On May 29, 2014, at 1:38 AM, Kishon Vijay Abraham I wrote:
>>
>>> The configuration address space has so far been specified in *ranges*,
>>> however it should be specified in *
On May 29, 2014, at 10:14 AM, Kumar Gala wrote:
>
> On Apr 24, 2014, at 11:31 AM, Andy Gross wrote:
>
>> This patch removes direct access of the GSBI registers. GSBI configuration
>> should be done through the GSBI driver directly.
>>
>> Signed-off-by: Andy Gross
>> ---
>> drivers/tty/seri
On Thu, May 29, 2014 at 6:05 AM, Steve Grubb wrote:
> On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote:
>> >> - It assumes that syscall numbers are between 0 and 2048.
>> >>
>> > There could well be a bug here. Not questioning that. Although that
>> > would be patch 1/2
>>
>> Even w
The problem,at least I think it's the same problem, also occurs in
kernel 2.6.17.1.
The relevant output has been posted online at
http://www.kennedy.aecom.yu.edu/misc/drbdstall2.htm
>
>/ 2006-06-08 20:34:10 -0400
>\ Maurice Volaski:
>> It appears that kernel 2.6.17-rc5 under amd64 may be hangin
It happened again, but this time on just one of the two computers:
[20770.844282] hda: tray open
[20770.844288] end_request: I/O error, dev hda, sector 0
[20770.844292] Buffer I/O error on device hda, logical block 0
Since you think LVM may be misbehaving, I changed the filter on the
affected co
It happened again, but this time on just one of the two computers:
[20770.844282] hda: tray open
[20770.844288] end_request: I/O error, dev hda, sector 0
[20770.844292] Buffer I/O error on device hda, logical block 0
Since you think LVM may be misbehaving, I changed the filter on the
affected co
The problem,at least I think it's the same problem, also occurs in
kernel 2.6.17.1.
The relevant output has been posted online at
http://www.kennedy.aecom.yu.edu/misc/drbdstall2.htm
>
>/ 2006-06-08 20:34:10 -0400
>\ Maurice Volaski:
>> It appears that kernel 2.6.17-rc5 under amd64 may be hangin
On Thu, May 29, 2014 at 2:07 PM, Miklos Szeredi wrote:
> On Thu, May 29, 2014 at 12:28:45PM +0100, David Howells wrote:
>>
>> This sequence of commands produces both errors:
Fixes pushed to overlayfs.v22 (and overlayfs.current). Will
eventually fold these into the main overlayfs patch.
Thanks,
Spontaneously and for no apparent reason, two computers displayed the
following message in their logs several times at the same time:
[55419.446442] Buffer I/O error on device hda, logical block 0
[55419.447381] hda: command error: status=0x51 { DriveReady
SeekComplete Error }
[55419.447386] hda
Spontaneously and for no apparent reason, two computers displayed the
following message in their logs several times at the same time:
[55419.446442] Buffer I/O error on device hda, logical block 0
[55419.447381] hda: command error: status=0x51 { DriveReady
SeekComplete Error }
[55419.447386] hda
First posted to drbd mailing list on 2/6 with no reply. It hasn't
happened since, but once is enough to mean something is wrong
somewhere.
I did a resize of all the underlying LVMs and that proceeded very
nicely since drbd automatically recognized the new sizes and
resize2fs automatically fi
On Thu, May 29, 2014 at 04:01:27PM +0900, Daeseok Youn wrote:
> This reverts commit 0ade4a34fd439d62df46937e8f3e584eb0879579.
>
> This patch removes kfree for serial_ports in dgap_tty_register_ports()
> if the "brd->printer_ports" allocation fails and serial_ports may be
> freed by calling dgap_tt
First posted to drbd mailing list on 2/6 with no reply. It hasn't
happened since, but once is enough to mean something is wrong
somewhere.
I did a resize of all the underlying LVMs and that proceeded very
nicely since drbd automatically recognized the new sizes and
resize2fs automatically fi
Update the default value to match the patch.
Signed-off-by: Richard Fitzgerald
---
drivers/mfd/wm5102-tables.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
index 9b9923c..02c44fd 100644
--- a/drivers/mfd/wm510
Currently, __GFP_NORETRY tries charging once and gives up before even
trying to reclaim. Bring the behavior on par with the page allocator
and reclaim at least once before giving up.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
When mem_cgroup_try_charge() returns -EINTR, it bypassed the charge to
the root memcg. But move precharging does not catch this and treats
this case as if no charge had happened, thus leaking a charge against
root. Because of an old optimization, the root memcg's res_counter is
not actually charg
Hi,
this is version 2 of the memcg charge naturalization series. Changes
since v1 include:
o document mem_cgroup_account_move() exclusion
o catch uncharged swapin readahead pages in mem_cgroup_swapout()
o fix DEBUG_VM build after last-minute identifier rename
o drop duplicate lru_cache_add_activ
Due to an old optimization to keep expensive res_counter changes at a
minimum, the root_mem_cgroup res_counter is never charged; there is no
limit at that level anyway, and any statistics can be generated on
demand by summing up the counters of all other cgroups.
However, with per-cpu charge cache
Kmem page charging and uncharging is serialized by means of exclusive
access to the page. Do not take the page_cgroup lock and don't set
pc->flags atomically.
Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
Acked-by: Vladimir Davydov
---
mm/memcontrol.c | 21 +++--
1 fil
The memcg charge API charges pages before they are rmapped - i.e. have
an actual "type" - and so every callsite needs its own set of charge
and uncharge functions to know what type is being operated on. Worse,
uncharge has to happen from a context that is still type-specific,
rather than at the en
Hi Bjorn,
On 27/05/14 18:28, Bjorn Andersson wrote:
Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
and 8064 based devices. The binding currently describes the rpm itself and the
regulator subnodes.
Signed-off-by: Bjorn Andersson
---
Documentation/devicetree/bin
There is no reason why oom-disabled and __GFP_NOFAIL charges should
try to reclaim only once when every other charge tries several times
before giving up. Make them all retry the same number of times.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 8
1 file changed, 4 insertions(
The charging path currently starts out with OOM condition checks when
OOM is the rarest possible case.
Rearrange this code to run OOM/task dying checks only after trying the
percpu charge and the res_counter charge and bail out before entering
reclaim. Attempting a charge does not hurt an (oom-)k
This function was split out because mem_cgroup_try_charge() got too
big. But having essentially one sequence of operations arbitrarily
split in half is not good for reworking the code. Fold it back in.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 166 ++-
There is a write barrier between setting pc->mem_cgroup and
PageCgroupUsed, which was added to allow LRU operations to lookup the
memcg LRU list of a page without acquiring the page_cgroup lock.
But ever since 38c5d72f3ebe ("memcg: simplify LRU handling by new
rule"), pages are ensured to be off-L
On Thu, May 29, 2014 at 6:06 PM, Miklos Szeredi wrote:
> On Thu, May 29, 2014 at 2:07 PM, Miklos Szeredi wrote:
>> On Thu, May 29, 2014 at 12:28:45PM +0100, David Howells wrote:
>>>
>>> This sequence of commands produces both errors:
>
> Fixes pushed to overlayfs.v22 (and overlayfs.current). Wil
Hi Bjorn,
On 27/05/14 18:28, Bjorn Andersson wrote:
Driver for the Resource Power Manager (RPM) found in Qualcomm 8660, 8960 and
8064 based devices. The driver exposes resources that child drivers can operate
on; to implementing regulator, clock and bus frequency drivers.
Signed-off-by: Bjorn A
On Thu, May 29, 2014 at 04:44:54PM +0100, Al Viro wrote:
> On Thu, May 29, 2014 at 08:10:57AM -0700, Linus Torvalds wrote:
> > If so, though, that brings up two questions:
> >
> > (a) do we really want to be that aggressive? Can we ever traverse
> > _past_ the point we're actually trying to shrin
Setting zero-length Smack label on a file crashes the kernel.
The following command:
# setfattr -n security.SMACK64 /dev/null
causes kernel panic. Call Trace:
[<601a3b1e>] smk_parse_smack+0x1e/0xb2
[<601a3cb0>] smk_import_entry+0x16/0x180
[<601a1d0f>] smack_inode_setxattr+0x1ac/0x269
[<6001ea
On 05/27/2014 10:26 AM, Peter Zijlstra wrote:
On Tue, May 27, 2014 at 10:18:31AM -0400, Jason J. Herne wrote:
On 05/16/2014 12:29 PM, Peter Zijlstra wrote:
On Sat, May 17, 2014 at 12:18:06AM +0800, Lai Jiangshan wrote:
so the scheduler/set_cpus_allowed_ptr()/cpu_active_mask should be the first
On Thu, 29 May 2014, Frederic Weisbecker wrote:
> > Well yes and I am tying directly into that scheme there in cpu.c to
> > display the active vmstat threads in sysfs. so its the same.
>
> I don't think so. Or is there something in vmstat that cpumask_var_t
> definition depends upon?
This patch d
Miklos Szeredi wrote:
> Fixes pushed to overlayfs.v22 (and overlayfs.current). Will
> eventually fold these into the main overlayfs patch.
Okay... those are fixed. Here's the next:
=
[ INFO: possible recursive locking detected ]
3.15.0-rc6-fsdevel+
On Thursday, May 29, 2014 09:04:10 AM Andy Lutomirski wrote:
> On Thu, May 29, 2014 at 6:05 AM, Steve Grubb wrote:
> > On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote:
> >> >> - It assumes that syscall numbers are between 0 and 2048.
> >> >>
> >> > There could well be a bug here. No
Signed-off-by: Kumar Gala
---
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index bfed753..42ebd72 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -131,6 +
On Thu, May 29, 2014 at 11:03:36AM -0500, Kumar Gala wrote:
> Just because the kernel doesn’t handle this is NO reason to change
> the way the DT works.
The OF specs do not specify how to process a config type ranges entry,
and we all mutually agreed that the only sane interpretation for such
a t
On May 29, 2014, at 11:19 AM, Srinivas Kandagatla
wrote:
>> += SUBDEVICES
>> +
>> +The RPM exposes resources to its subnodes. The below bindings specify the
>> set
>> +of valid subnodes that can operate on these resources.
>
> Why should these devices be on sub nodes?
>
> Any reason not to i
On Thu, May 29, 2014 at 9:23 AM, Al Viro wrote:
>
> BTW, lock_parent() might be better off if in contended case it would not
> bother with rename_lock and did something like this:
> again:
Ack. I think that's much better.
Linus
--
To unsubscribe from this list: send the line "unsubs
On Thu, May 29, 2014 at 04:26:05PM +0200, Frederic Weisbecker wrote:
> On Thu, May 29, 2014 at 09:07:44AM -0500, Christoph Lameter wrote:
> > On Thu, 29 May 2014, Frederic Weisbecker wrote:
> >
> > > The cpumasks in cpu.c are special as they are the base of the
> > > cpumask_var_t
> > > definitio
On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
The configuration address space has so far been specified in *ranges*,
however it should be specified in *reg* making it a platform MEM resource.
Hence used 'platform_get_resource_*' API to get configuration address
space in the designware driver
On Wed, 2014-05-28 at 23:26 -0400, George Spelvin wrote:
> > Can you do a tcrypt speed measurement with and without your changes?
> > Check to see if there's any slowdown. Please make sure you pin
> > the frequency of your cpu when running the test.
> >
> > e.g.
> > echo performance > /sys/devi
Quoting Alex Elder (2014-05-29 06:26:15)
> On 05/23/2014 07:53 PM, Mike Turquette wrote:
> > The above seems like a lot effort to go to. Why not skip all of this and
> > just implement the prerequisite logic in the .enable & .disable
> > callbacks? E.g. your kona clk .enable callback would look lik
There appears to have been a merge error on commit:
2b76813: drm/exynos: hdmi: remove the i2c drivers and use
The original submission can be found at:
https://patchwork.kernel.org/patch/3559541/
It looks like the commit was only half applied. This patch aims
to finish what was started by D
On Thu, May 29, 2014 at 05:23:22PM +0100, David Howells wrote:
> Miklos Szeredi wrote:
>
> > Fixes pushed to overlayfs.v22 (and overlayfs.current). Will
> > eventually fold these into the main overlayfs patch.
>
> Okay... those are fixed. Here's the next:
>
generic_file_splice_write() uses I
On Thu, May 29, 2014 at 11:24:15AM -0500, Christoph Lameter wrote:
> On Thu, 29 May 2014, Frederic Weisbecker wrote:
>
> > > Well yes and I am tying directly into that scheme there in cpu.c to
> > > display the active vmstat threads in sysfs. so its the same.
> >
> > I don't think so. Or is there
Hi.
On 29.05.2014 18:36, Lee Jones wrote:
> There appears to have been a merge error on commit:
>
> 2b76813: drm/exynos: hdmi: remove the i2c drivers and use
>
> The original submission can be found at:
>
> https://patchwork.kernel.org/patch/3559541/
>
> It looks like the commit was only h
Removed dead code from the file.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8192U_wx.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u/r8192U_wx.c
index 09b1e81..ceb06d8 10
Removed dead code, commented out printks and DMESG.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8192U_wx.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u/r8192U_wx.c
index 675a12d..7dc2a96 100644
Added a space around '|' to address:
ERROR: need consistent spacing around '|' (ctx:VxW)
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8192U_wx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u
On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
>> It doesn't work out well because we later lock a mutex in sync_child_event().
>>
>
> Urgh, right you are. I'll go stare at it more. It shouldn't have
> mattered, because the mutex we tak
To address the error -
ERROR: do not use C99 // comments
Removed all C99 comments.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8192U_wx.c | 130 +--
1 file changed, 65 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192
Miklos Szeredi wrote:
> generic_file_splice_write() uses I_MUTEX_CHILD. Not sure why, though, parent
> shouldn't be locked. Maybe it's some remaining thing from the days when pipes
> used the i_mutex on the pipe inode. Probably should just remove that notation
> and things will work.
You shou
Fixed a misplaced brace in the r8192_wx_set_scan_type function.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r8192U_wx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u/r8192U_wx.c
index 1af7c
On Thu, May 29, 2014 at 9:25 AM, Steve Grubb wrote:
> On Thursday, May 29, 2014 09:04:10 AM Andy Lutomirski wrote:
>> On Thu, May 29, 2014 at 6:05 AM, Steve Grubb wrote:
>> > On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote:
>> >> >> - It assumes that syscall numbers are between 0 an
On Thursday, May 29, 2014 5:29 AM, Ian Abbott wrote:
> From: Fred Brooks
>
> Add support for switching the input range and the single-ended/
> differential input mode for the AI subdevice. We needed to clear the
> FIFO of data before the conversion to handle card mode switching
> glitches.
>
> [
http://git.infradead.org/users/dhowells/unionmount-testsuite.git
Check it out and read the README file as to how to drive it. Sorry, it's a
bit crude. I may rewrite it in python or perl at some point.
Make sure you turn on CONFIG_LOCKDEP before running it - you don't want to
miss any locking c
On Thursday, May 29, 2014 4:16 AM, Ian Abbott wrote:
>
> Reformat the comment describing this comedi driver to use the usual
> block comment format.
>
> Also remove reference to digital I/O emulating an 8255, because it
> doesn't, and remove "DIO only" from the "Description:" line as it also
> supp
On Thu, May 29, 2014 at 03:29:12PM +0100, Lorenzo Pieralisi wrote:
> On Thu, May 29, 2014 at 01:39:29PM +0100, Mark Rutland wrote:
>
> [...]
>
> > > > The side effect of having a CPU always-on has implications on power
> > > > management
> > > > platform capabilities and makes CPUidle suboptimal
On Thu, May 29, 2014 at 12:44:23PM -0400, Sasha Levin wrote:
> On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> > On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
> >> It doesn't work out well because we later lock a mutex in
> >> sync_child_event().
> >>
> >
> > Urgh, right you are. I
On May 29, 2014, at 11:30 AM, Jason Gunthorpe
wrote:
> On Thu, May 29, 2014 at 11:03:36AM -0500, Kumar Gala wrote:
>
>> Just because the kernel doesn’t handle this is NO reason to change
>> the way the DT works.
>
> The OF specs do not specify how to process a config type ranges entry,
> and
Checks for CONFIG_BCM_CS4297A_CSWARM were added in v2.6.11. The related
Kconfig symbol was never added so these checks always evaluated to true.
Remove them.
Signed-off-by: Paul Bolle
---
Untested.
sound/oss/swarm_cs4297a.c | 4
1 file changed, 4 deletions(-)
diff --git a/sound/oss/swarm_
On 05/29/2014 12:50 PM, Peter Zijlstra wrote:
>> >
>> > So the only caller to sync_child_event() is that loop. According to what
>> > you said
>> > it should be safe to remove that mutex lock, but doing that triggers a list
>> > corruption:
>> >
>> > [ 1204.341887] WARNING: CPU: 20 PID: 12839 at
On Thu, May 29, 2014 at 09:29:42AM -0700, Linus Torvalds wrote:
> On Thu, May 29, 2014 at 9:23 AM, Al Viro wrote:
> >
> > BTW, lock_parent() might be better off if in contended case it would not
> > bother with rename_lock and did something like this:
> > again:
>
> Ack. I think that's much bette
On 05/29/2014 11:35 AM, Mike Turquette wrote:
> Quoting Alex Elder (2014-05-29 06:26:15)
>> On 05/23/2014 07:53 PM, Mike Turquette wrote:
>>> The above seems like a lot effort to go to. Why not skip all of this and
>>> just implement the prerequisite logic in the .enable & .disable
>>> callbacks? E
> Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960
> and 8064 based devices. The binding currently describes the rpm itself and the
> regulator subnodes.
>
> Signed-off-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284
> ++
Checks for CONFIG_SND_DEBUG_ROM were added in v2.5.5 but a Kconfig
symbol SND_DEBUG_ROM was never added. These checks have always
evaluated to false. Remove them and the printk()s they hide.
Signed-off-by: Paul Bolle
---
Untested.
Perhaps one is expected to define this debugging macro by hand, s
On Thu, May 29, 2014 at 06:50:57PM +0200, Peter Zijlstra wrote:
> On Thu, May 29, 2014 at 12:44:23PM -0400, Sasha Levin wrote:
> > On 05/29/2014 11:07 AM, Peter Zijlstra wrote:
> > > On Thu, May 29, 2014 at 10:47:09AM -0400, Sasha Levin wrote:
> > >> It doesn't work out well because we later lock a
> OK, I'll take this.
If you didn't already apply it, then add a "Reviewed-by: Tony Luck
"
I see that this patch is on top of my earlier ones (includes the
"force_early" argument).
That means you have both of those queued too?
Thanks
-Tony
--
To unsubscribe from this list: send the line "unsubs
On 29/05/14 17:30, Kumar Gala wrote:
On May 29, 2014, at 11:19 AM, Srinivas Kandagatla
wrote:
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
Why should these devices be on sub nodes?
This fixes a problem with dropped packets over 16k CDC-NCM
when the connection is being heavily used.
The issue was that the skb truesize for the unpacked NCM
packets was too high after they were cloned from the 16k
skb, this lead to the potential memory calculated by the
Kernel running out of mem
The NDP was ignoring the wNextNdpIndex in the NDP which
means that NTBs containing multiple NDPs would have missed
frames.
Signed-off-by: Jim Baxter
---
drivers/usb/gadget/f_ncm.c | 146 +++-
1 file changed, 78 insertions(+), 68 deletions(-)
diff --git a
This series adds the ability to support packaging multiple network
packets into a single 16k CDC-NCM NTB.
Patches 1 and 3 are fixes for the receive unwrap function which
previously was unable to handle an NTB with multiple NDP's and a fix
that switches from using skb_clone to creating a new packet
This adds multi-frame support to the NCM NTB's for
the gadget driver. This allows multiple network
packets to be put inside a single USB NTB with a
maximum size of 16kB.
It has a time out of 300ms to ensure that smaller
number of packets still maintain a normal latency.
Also the .fp_index and .ne
On Mon, May 26, 2014 at 06:41:22PM -0300, Gustavo Padovan wrote:
> Hi John,
>
> Some more patches for 3.16. There is nothing really special here, just a
> bunch of clean ups, fixes plus some small improvements. Please pull.
>
> Thanks!
>
> Gustavo
>
> ---
>
> The following changes since
On Thu, May 29, 2014 at 10:38:32AM -0400, Johannes Weiner wrote:
> Hi Mel!
>
> On Thu, May 29, 2014 at 10:04:32AM +0100, Mel Gorman wrote:
> > The fair zone allocation policy round-robins allocations between zones on
> > a node to avoid age inversion problems during reclaim using a counter to
> >
On Thu, 29 May 2014, Nikita Yushchenko wrote:
> >> I've checked these... all values read as 0x - which does not
> >> look correct
> >
> > You could have the platform setup code read one of those hardware
> > registers, such as FMINTERVAL. If it obtains 0x, don't
> > register the
401 - 500 of 908 matches
Mail list logo
