Hi Fabio,
Am 17.12.2014 um 03:44 schrieb Fabio Estevam:
> Hi Stefan,
>
> On Sun, Dec 14, 2014 at 3:16 PM, Stefan Wahren wrote:
>
>> Btw i hope this patch also fixes a SPI communication issue with our hardware
>> which forces us to bypass ref_io1 for ssp2.
> Does this patch fix the SPI issue?
On Tue, Dec 16, 2014 at 10:24:00PM -0600, Chris Rorvick wrote:
> Added a second patch to address Dan Carpenter's concern with the
> complexity of passing the sign through `mult'. Compile tested only.
Thanks. That does look cleaner.
regards,
dan carpenter
--
To unsubscribe from this list:
On 2 December 2014 at 15:06, Morten Rasmussen wrote:
> From: Morten Rasmussen
>
> Architectures that don't have any other means for tracking cpu frequency
> changes need a callback from cpufreq to implement a scaling factor to
> enable scale-invariant per-entity load-tracking in the scheduler.
>
On Wed, 17 Dec 2014, Peter Wu wrote:
> Previously wtp_raw_event would be called through
> hidpp_raw_hidpp_event (for the touchpad report) and hidpp_raw_event
> (for the mouse report).
>
> This patch removes one calling surface, making a clearer distinction
> between "generic HID++ processing"
On Tue, 16 Dec 2014, Peter Wu wrote:
> Malicious USB devices can send bogus reports smaller than the expected
> buffer size. Ensure that the length is valid to avoid reading out of
> bounds.
>
> Signed-off-by: Peter Wu
> ---
> v1: patch 2/3 HID: logitech-{dj,hidpp}: check report length
> v2:
On Tue, 16 Dec 2014, Peter Wu wrote:
> Malicious USB devices can send bogus reports smaller than the expected
> buffer size. Ensure that the length for WTP reports is valid to avoid
> reading out of bounds.
>
> Signed-off-by: Peter Wu
> ---
> v1: patch 2/3 HID: logitech-{dj,hidpp}: check
On Wed, Dec 17, 2014 at 12:16 PM, Jiri Kosina wrote:
> On Wed, 17 Dec 2014, Balbir Singh wrote:
>
>> >> Could you describe what this does to signing? I presume the patched
>> >> module should cause a taint on module signing?
>> >
>> > Hmm, why should it?
>>
>> I wanted to clarify it from a
On Wed, Dec 17, 2014 at 12:57 AM, Octavian Purdila
wrote:
> As noticed during suspend/resume operations, the IRQ can be unmasked
> then disabled in suspend and eventually enabled in resume, but without
> being unmasked.
>
> The current implementation does not take into account interactions
>
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol can be done
By two methods, which are to use EVCR(Enhanced Volatile Configuration Register)
and the ENTER QUAD I/O MODE command. There is no difference
The rule which delivers this warning is very prone to errors:
"added, moved or deleted file(s), does MAINTAINERS need updating?"
so it should not be enabled by default.
The current checkpatch rule doesn't check:
1. whether other patches in the same series update MAINTAINERS
2. whether
On Thu, Dec 11, 2014 at 12:25 AM, Ricardo Ribalda Delgado
wrote:
> Some documentation were not following the kernel-doc format.
> Backporting patch from Xilinx git repository.
>
> Suggested-by: Michal Simek
> Signed-off-by: Ricardo Ribalda Delgado
Acked-by: Alexandre Courbot
--
To unsubscribe
On Thu, Dec 11, 2014 at 12:56 AM, Ricardo Ribalda Delgado
wrote:
> This way we do not need to transverse the device tree manually and we
> support hot plugged devices.
>
> Also Implement remove callback so the driver can be unloaded
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
>
> v4: Add
2014-12-17 0:48 GMT+09:00 Christoph Lameter :
> On Tue, 16 Dec 2014, Jesper Dangaard Brouer wrote:
>
>> > Ok but now there is a multiplication in the fast path.
>>
>> Could we pre-calculate the value (page->objects * s->size) and e.g store it
>> in struct kmem_cache, thus saving the imul ?
>
> I
2014-12-15 16:59 GMT+09:00 Joonsoo Kim :
> On Wed, Dec 10, 2014 at 10:30:17AM -0600, Christoph Lameter wrote:
>> We had to insert a preempt enable/disable in the fastpath a while ago. This
>> was mainly due to a lot of state that is kept to be allocating from the per
>> cpu freelist. In particular
Hello, Minchan
Thanks for your review.
2014-12-16 10:45 GMT+08:00 Minchan Kim :
> On Sat, Dec 13, 2014 at 09:45:14PM +0800, Ganesh Mahendran wrote:
>> As a ram based memory allocator, keep the fragmentation in a low level
>
> Just say, zsmalloc.
Ok.
>
>> is our target. But now we still need to
On Mon, Dec 15, 2014 at 02:37:04PM +0100, Geert Uytterhoeven wrote:
> If NO_DMA=y:
>
> drivers/built-in.o: In function `sh_mobile_i2c_dma_unmap':
> i2c-sh_mobile.c:(.text+0x60de42): undefined reference to `dma_unmap_single'
> drivers/built-in.o: In function `sh_mobile_i2c_xfer_dma':
>
On 2014/12/16, 9:24 PM, "Chris Rorvick" wrote:
>The `mult' parameter is negated if the user data begins with a '-' so
>that the final value has the appropriate sign. But `mult' is only used
>if the user data does not include a "units" suffix. In this case,
>`mult' is overridden with the
all,
On Tue, Dec 16, 2014 at 12:24:37PM -0800, Benson Leung wrote:
> On Tue, Dec 16, 2014 at 5:56 AM, Jeremiah Mahler wrote:
> > On Mon, Dec 15, 2014 at 02:23:20PM +0800, Dudley Du wrote:
> >> Add firmware image update function supported for gen5 trackpad device,
> >> it can be used through
On Wed, 17 Dec 2014, Balbir Singh wrote:
> >> Could you describe what this does to signing? I presume the patched
> >> module should cause a taint on module signing?
> >
> > Hmm, why should it?
>
> I wanted to clarify it from a different perspective
>
> If the base image is signed by X and the
Dear Madam/Sir,
Hello,very glad to got your message on website market.Our company manufacturing
high-quality and competitively priced items .Our main products include medals
and other promotional items.If you are interested on us,please let me know. I
am Jennifer from Sonier.
King regards,
On Tue, Dec 16, 2014 at 10:18 AM, Bjorn Andersson wrote:
> We are routing the regulators straight to vdd of the memory and should
> hence use vmmc to specify this. However unless I actually program 0x29
> in the Qualcomm sdhci block I get no responses from the card.
>
> Which I believe is
Hi Zubair,
Several comments inline.
On Tue, Dec 16, 2014 at 04:33:44PM +, Zubair Lutfullah Kakakhel wrote:
> In boards, the dm9000 chip's power and reset can be controlled by gpio.
>
> It makes sense to add them to the dm9000 driver and let dt be used to
> enable power and reset the phy.
>
Hi, Mark
On Mon, Dec 15, 2014 at 9:38 PM, Mark Rutland wrote:
> On Fri, Dec 05, 2014 at 12:27:23PM +, Lyra Zhang wrote:
>> On Fri, Dec 5, 2014 at 6:40 PM, Mark Rutland wrote:
>> > Hi,
>> >
>> > On Thu, Dec 04, 2014 at 11:34:15AM +, Chunyan Zhang wrote:
>> >> Spreadtrum is a rapid
Hi Chao,
On Thu, Dec 11, 2014 at 06:16:27PM +0800, Chao Yu wrote:
> Use more common function ra_meta_pages() with META_POR to readahead node
> blocks
> in restore_node_summary() instead of ra_sum_pages(), hence we can simplify the
> readahead code there, and also we can remove unused function
On Wed, Dec 10, 2014 at 10:36 PM, Geert Uytterhoeven
wrote:
> The pcf857x GPIO and interrupt controller uses dummy_irq_chip, which
> does not implement irq_chip.irq_set_wake() and does not set
> IRQCHIP_SKIP_SET_WAKE.
>
> This causes two s2ram issues if wake-up is enabled for the pcf857x GPIO
>
Hi all,
Please do not add any code destined for v3.20 to your linux-next included
trees/branches until after v3.19-rc1 is released.
Changes since 20141216:
The infiniband tree lost its build failure.
The ipmi tree gained a build failure so I used the version form
next-20141216.
The clk tree
Hi Thomas,
Should I keep the development history or start from scratch
for this ACPI resource patch set?
Thanks!
Gerry
On 2014/12/12 19:43, Thomas Gleixner wrote:
> On Fri, 12 Dec 2014, Jiang Liu wrote:
>> On 2014/12/12 15:53, Thomas Gleixner wrote:
>>> On Thu, 11 Dec 2014, Yinghai Lu
Thanks,
>From what I understand, there is indeed a virtual processor bug. It's
fixed in HardWare Version 11, so that the PAT registers return the
correct value.
Thanks,
Thomas
On 12/17/2014 03:46 AM, Jongman Heo wrote:
> Hi,
>
> I'm using VMWare workstation, version 10.0.3 build-1895310, on
Hi Russell,
Could you please collect this patch and merge it into your repository first? Due
to this is a source tree layout modification, others may work on original files
and experiences unneed conflicts.
Thank you.
On 2014/12/12 18:51, Masami Hiramatsu wrote:
> (2014/12/11 19:04), Wang Nan
On Tue, 16 Dec 2014 23:19:09 -0500 nick wrote:
> Greetings Neil,
> As you our the maintainer for this patch I created:
>
> >From ad324f9c2c8117b2f74ad73cb9c6e8185edf5395 Mon Sep 17 00:00:00 2001
> From: Nicholas Krause
> Date: Tue, 16 Dec 2014 22:54:10 -0500
> Subject: [PATCH] drivers:md:
On Tue, Dec 16, 2014 at 11:31:33PM +0100, Borislav Petkov wrote:
> On Tue, Dec 16, 2014 at 02:19:02PM -0800, Kevin Cernekee wrote:
> > In the current process, many submitters do not know their maintainer's
> > policy until they get in trouble for violating it.
>
> Just say what Christoph
This patch adds a reusable time difference function which returns the
difference in millisecond, as often used in some driver code, e.g.
mtd/test, media/rc, etc.
Signed-off-by: Chunyan Zhang
---
include/linux/ktime.h |5 +
1 file changed, 5 insertions(+)
diff --git
On Wed, Dec 17, 2014 at 02:46:02AM +, Al Viro wrote:
>
> a) learn to use line breaks
> b) what do we win from removing it? If it starts becoming inconvenient to
> maintain, it might make sense to consider removal, but as it is... What,
> somebody has slapped a couple of F-words in there?
Hi,
On Tue, 2014-12-16 at 10:58 +0100, Juergen Gross wrote:
> VMWare seems not to emulate the PAT MSR correctly: reaeding
> MSR_IA32_CR_PAT returns 0 even after writing another value to it.
>
> Detect this bug and don't use the read value if it is 0.
>
> Commit
(2014/12/17 12:22), Kamezawa Hiroyuki wrote:
(2014/12/17 10:36), Lai Jiangshan wrote:
On 12/17/2014 12:45 AM, Kamezawa Hiroyuki wrote:
With node online/offline, cpu<->node relationship is established.
Workqueue uses a info which was established at boot time but
it may be changed by node
On 12/16/2014 05:47 PM, H. Peter Anvin wrote:
On 12/16/2014 01:58 AM, Juergen Gross wrote:
VMWare seems not to emulate the PAT MSR correctly: reaeding
MSR_IA32_CR_PAT returns 0 even after writing another value to it.
Detect this bug and don't use the read value if it is 0.
Commit
>> +{ "n25q032", INFO(0x20ba16, 0, 64 * 1024, 64, SPI_NOR_QUAD_READ)
>> },
>> +{ "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, SPI_NOR_QUAD_READ)
>> },
>> +{ "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, SPI_NOR_QUAD_READ)
>> },
>> +{ "n25q128a13", INFO(0x20ba18,
On 17 December 2014 at 04:39, Dmitry Torokhov wrote:
> Note that I am not happy with OPP code: dev_pm_opp_init_cpufreq_table() is
> wrong in it's assumption that taking RCU lock will guarantee that number of
> OPPs will not change - we can remove OPP from list just fine, and then
> initialization
From: Thomas Gleixner
The whole iommu setup for irq remapping is a convoluted mess. The
iommu detect function gets called from mem_init() and the prepare
callback gets called from enable_IR_x2apic() for unknown reasons.
Of course AMD and Intel setup differs in nonsensical ways. Intels
prepare
On 17 December 2014 at 04:39, Dmitry Torokhov wrote:
> cpufreq-dt driver supports mode when OPP table is provided by platform
> code and not device tree. However on certain platforms code that fills
> OPP table may run after cpufreq driver tries to initialize, so let's
> report -EPROBE_DEFER if
On 17 December 2014 at 04:39, Dmitry Torokhov wrote:
> A lot of callers are missing the fact that dev_pm_opp_get_opp_count
> needs to be called under RCU lock. Given that RCU locks can safely be
> nested, instead of providing *_locked() API, let's take RCU lock inside
Hmm, I asked for a
Refine enable_IR_x2apic() and related functions for better readability.
It also changes the way to handle IR in XAPIC mode when enabling X2APIC.
Previously it just skips X2APIC initialization without checking max CPU
APIC ID in system, which may cause problem if system has CPU with APIC
ID bigger
From: Joerg Roedel
IRQ remapping is only supported when all IOMMUs in the
system support it. So check if all IOMMUs in the system
support IRQ remapping before doing the allocations.
[Jiang]
1) Rebased onto v3.19.
2) Remove redundant check of ecap_ir_support(iommu->ecap) in function
Simplify irq_remapping code by killing irq_remapping_supported() and
related interfaces.
Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h |
Assign intel_irq_remap_ops to remap_ops only if
intel_irq_remap_ops.prepare() succeeds.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
Prepare for killing function irq_remapping_supported() by moving code
from intel_irq_remapping_supported() into intel_prepare_irq_remapping().
Combined with patch from Joerg at https://lkml.org/lkml/2014/12/15/487,
so assume an signed-off from Joerg.
Signed-off-by: Jiang Liu
Signed-off-by:
When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system
may panic or hang without useful messages. On the other hand, it's
hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled.
So panic with a clear message in such a case.
System panics as below when X2APIC is
From: Joerg Roedel
This allows to get rid of the irq_remapping_supported()
function and all its call-backs into the Intel and AMD
IOMMU drivers.
Signed-off-by: Joerg Roedel
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu_init.c |3 +++
1 file changed, 3 insertions(+)
diff --git
X2APIC will be disabled if user specifies "nox2apic" on kernel command
line, even when x2apic_preenabled is true. So correctly detect X2APIC
status by using x2apic_enabled() instead of x2apic_preenabled.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/apic.c |2 +-
1 file changed, 1
Refine code by normailizing the way to detect whether IR is enabled.
Signed-off-by: Jiang Liu
---
drivers/iommu/irq_remapping.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c
When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode
will be disabled if:
1) Maximum CPU APIC ID is bigger than 255
2) hypervisior doesn't support x2apic mode.
But we should only check whether hypervisor supports X2APIC mode when
hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled,
Change variable disable_irq_remap to be static and simplify the code.
Signed-off-by: Jiang Liu
---
drivers/iommu/amd_iommu_init.c |6 +-
drivers/iommu/intel_irq_remapping.c |5 -
drivers/iommu/irq_remapping.c |3 +--
drivers/iommu/irq_remapping.h |2 --
Currently if CPU supports X2APIC, IR hardware must work in X2APIC mode
or disabled. Change the code to support IR working in XAPIC mode when
CPU supports X2APIC. Then the CPU APIC driver will decide how to handle
such as configuration by:
1) Disabling X2APIC mode
2) Forcing X2APIC physical mode
Local variable x2apic_enabled has been assigned to but never referred,
so kill it.
Signed-off-by: Jiang Liu
---
arch/x86/kernel/apic/apic.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index
From: Thomas Gleixner
No reason anymore to do GFP_ATOMIC allocations which are not harmful
in the normal bootup case, but matter in the physical hotplug
scenario.
Signed-off-by: Thomas Gleixner
Tested-by: Borislav Petkov
Acked-by: Joerg Roedel
Cc: Jiang Liu
Cc: x...@kernel.org
Link:
From: Thomas Gleixner
enable_IR_x2apic() calls setup_irq_remapping_ops() which by default
installs the intel dmar remapping ops and then calls the amd iommu irq
remapping prepare callback to figure out whether we are running on an
AMD machine with irq remapping hardware.
Right after that it
When converting x86 to new hierarchy irqdoamin framework, Thomas noticed
that the interrupt remapping initialization flow is a little complex and
has troubles in memory allocation. Then there is a joint force to
simplify IR initialization flow, please refer to related threads at:
From: Thomas Gleixner
There is no reason to keep preemption disabled in this function.
We only have two other threads live: kthreadd and idle. Neither of
them is going to preempt. But that preempt_disable forces all the code
inside to do GFP_ATOMIC allocations which is just insane.
Remove it.
On 17 December 2014 at 04:39, Dmitry Torokhov wrote:
> Not having OPP defined for a device is not a crime, we should not splat
> warning in this case. Also, it seems that we are ready to accept invalid
> dev (find_device_opp will return ERR_PTR(-EINVAL) then) so let's not
> crash in dev_name() in
Dear Sir/Madam,
Halo,We have done promotional gifts like souvenir coins and stones since 2003,
we have 6 designers customized new items in just 3 hours. 11 years’ experience
of producing metal pins could ensure the high quality of your project. If any
require, welcome to contact us.My name is
The `mult' parameter is negated if the user data begins with a '-' so
that the final value has the appropriate sign. But `mult' is only used
if the user data does not include a "units" suffix. In this case,
`mult' is overridden with the numeric scale conveyed by the units suffix,
but retains the
Added a second patch to address Dan Carpenter's concern with the
complexity of passing the sign through `mult'. Compile tested only.
Chris Rorvick (2):
drivers: staging: lustre: Use mult if units not specified
drivers: staging: lustre: Track sign separately
Units can be passed to lprocfs_write_frac_u64_helper() via a suffix
(e.g., "...K", "...M", etc.) tacked onto the value. A comment states
that "specified units override the multiplier," though the multiplier is
overridden regardless. Update the conditional logic so that it only
applies when units
On Dec 17 2014 or thereabouts, Peter Wu wrote:
> Sorry for the rapid mail, I forgot to mention something.
>
> wtp_connect won't work on non-HID++ devices. What about moving it down,
> between the generic routines (reading protocol and name) and
> hidpp_allocate_input? Then the connected parameter
directory
> #include
> ^
>
> Caused by commit 707096b4dd41 ("ipmi: Fix compile issue with isspace()").
>
> I have used the ipmi tree from next-20141216 for today.
>
> Also, you seem to have rebased your tree and thus duplicated a whole
> series of commits that a
On 17 December 2014 at 04:39, Dmitry Torokhov wrote:
> Certain OPP APIs need to be called under RCU lock; let's add a few
> rcu_lockdep_assert() calls to warn about potential misuse.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/base/power/opp.c | 16
> 1 file changed, 16
Hi Mike,
On Mon, 15 Dec 2014 23:20:34 -0800 Mike Turquette wrote:
>
> Quoting Stephen Rothwell (2014-12-15 19:45:36)
> > Hi Mike,
> >
> > After merging the clk tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from
On Wed, Dec 17, 2014 at 1:44 AM, Jiri Kosina wrote:
> On Tue, 16 Dec 2014, Balbir Singh wrote:
>
>> Could you describe what this does to signing? I presume the patched
>> module should cause a taint on module signing?
>
> Hmm, why should it?
>
I wanted to clarify it from a different perspective
On Wed, Dec 17, 2014 at 12:35 AM, Seth Jennings wrote:
> On Tue, Dec 16, 2014 at 11:45:12PM +0530, Balbir Singh wrote:
>> On Tue, Dec 16, 2014 at 11:28 PM, Seth Jennings wrote:
>> >
>> > Changelog:
>> >
>> > Thanks for all the feedback!
>> >
>>
>> Could you describe what this does to signing? I
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim
---
arch/arm/boot/dts/exynos3250-monk.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index
This patch series adds regulator-haptic driver.
The regulator-haptic has haptic motor and it is controlled by
voltage of regulator via force feedback framework.
Changes in v7:
- move platform_data or of_node check.
- prevent to start playing effect when kernel entering suspend state.
Changes
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim
Signed-off-by: Hyunhee Kim
Acked-by: Kyungmin Park
Tested-by: Chanwoo Choi
Reviewed-by: Chanwoo Choi
Reviewed-by:
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim
Reviewed-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-rinato.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
On Fri, Dec 05, 2014 at 07:09:59AM +, Bean Huo 霍斌斌 (beanhuo) wrote:
> This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
>
> For Micron SPI NOR flash,enabling or disabling quad I/O protocol can be done
> By two methods, which are to use EVCR(Enhanced Volatile
(2014/12/17 10:36), Lai Jiangshan wrote:
On 12/17/2014 12:45 AM, Kamezawa Hiroyuki wrote:
With node online/offline, cpu<->node relationship is established.
Workqueue uses a info which was established at boot time but
it may be changed by node hotpluging.
Once pool->node points to a stale node,
Add the verification code for returned __rtc_read_time() error in
rtc_update_irq_enable() and rtc_timer_do_work().
Signed-off-by: Hyogi Gim
---
drivers/rtc/interface.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/interface.c
On Tue, Dec 16, 2014 at 9:05 PM, Michael S. Tsirkin
wrote:
Use TUNSETVNETLE/TUNGETVNETLE instead.
Signed-off-by: Michael S. Tsirkin
---
drivers/net/tun.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
The automatic CPU power state machine for B15 CPUs does not work
reliably as-is. This patch implements a manual sequence in software to
replace it.
This was tested successfully with over 10,000 hotplug cycles of
something like this:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 1 >
On Tue, Dec 16, 2014 at 9:04 PM, Michael S. Tsirkin
wrote:
Dan Carpenter reported the following:
static checker warning:
drivers/net/tun.c:1694 tun_set_iff()
warn: 0x17100 is larger than 16 bits
drivers/net/tun.c
1692
1693
On 2014/12/17 10:29, Stephane Eranian wrote:
> On Wed, Dec 17, 2014 at 3:20 AM, Zefan Li wrote:
>> On 2014/12/17 1:17, Vince Weaver wrote:
>>> On Mon, 15 Dec 2014, Stephane Eranian wrote:
On Mon, Dec 15, 2014 at 11:01 PM, Arnaldo Carvalho de Melo
wrote:
>>>
fs is visible. The
issue with isspace()").
I have used the ipmi tree from next-20141216 for today.
Also, you seem to have rebased your tree and thus duplicated a whole
series of commits that are now in Linus' tree :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp0iNcAtDFrJ.pgp
D
The inotify kernel interface was removed by Eric Paris
in this commit: 2dfc1ca inotify: remove inotify in
kernel interface.
Signed-off-by: Zhang Zhen
---
Documentation/filesystems/inotify.txt | 120 +-
1 file changed, 2 insertions(+), 118 deletions(-)
diff --git
On Dec 17 2014 or thereabouts, Peter Wu wrote:
> Hi Benjamin,
>
> On Tuesday 16 December 2014 17:13:05 Benjamin Tissoires wrote:
> > the logitech patches are queuing up really fast.
> > To keep track of them, I made a bundle on patchwork:
> >
On Tue, Dec 16, 2014 at 6:57 AM, Arnd Bergmann wrote:
> On Monday 15 December 2014 13:35:47 Ray Jui wrote:
>>
>> Like I said previously, dynamic GPIO allocation works fine in the
>> kernel, as long as all of our GPIO clients in the kernel use gpiod based
>> API, which is what we will enforce
Hi,
I'm using VMWare workstation, version 10.0.3 build-1895310, on Windows 7 64-bit.
Guest is Fedora 21.
--- Original Message ---
Sender : Thomas Hellstrom
Date : 2014-12-17 00:12 (GMT+09:00)
Title : Re: [3.18+] Can't boot with commit bd809af1 ("x86: Enable PAT to use
cache mode
From: Fenghua Yu
X86 32-bit machine and kernel use PAE paging, which currently wastes about
4K of memory per process on Linux where we have to reserve an entire page to
support a single 256-byte PGD structure. It would be a very good thing if
we could eliminate that wastage.
Signed-off-by:
On Tue, Dec 16, 2014 at 09:14:16PM -0500, nick wrote:
> Greetings Andrew and others,
> I am wondering as cramfs as been marked obsolete for a while why haven't it
> been removed? If one of the maintainers can explain why that would be greatly
> be appreciated. Otherwise I am recommending if
On Sat, Dec 13, 2014 at 12:28 AM, Arnd Bergmann wrote:
> On Friday 12 December 2014 22:05:37 Alexandre Courbot wrote:
>> On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann wrote:
>> > On Thursday 11 December 2014 16:05:04 Ray Jui wrote:
>> >> +
>> >> +- linux,gpio-base:
>> >> +Base GPIO number
Hi Stefan,
On Sun, Dec 14, 2014 at 3:16 PM, Stefan Wahren wrote:
> Btw i hope this patch also fixes a SPI communication issue with our hardware
> which forces us to bypass ref_io1 for ssp2.
Does this patch fix the SPI issue?
--
To unsubscribe from this list: send the line "unsubscribe
On Dec 17 2014 or thereabouts, Peter Wu wrote:
> On Tuesday 16 December 2014 17:06:02 Benjamin Tissoires wrote:
> > If a disconnect occurs while getting the actual name of the device
> > (which can take several HID transactions), the name of the device will
> > be the hid name, provided by the
On Tue, Dec 16, 2014 at 4:40 PM, Marek Szyprowski
wrote:
> Hello,
>
> On 2014-12-13 17:51, Amit Daniel Kachhap wrote:
>>
>> Instead of using bool to restore suspended devices initially, use flags
>> like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE.
>> The first two flags
On 2014/12/17 1:29, Dimitri Sivanich wrote:
> I answered my own question, this had never been tested on UV.
>
> The gru driver fails with:
> SGI GRU Device Driver: uv_setup_irq failed, errno=22
>
> The info->type in uv_domain_alloc() is not set to X86_IRQ_ALLOC_TYPE_UV
> (info->type is
From: Kuninori Morimoto
Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process. But, almost all
Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
On Wed, Dec 17, 2014 at 3:53 AM, Suman Anna wrote:
>>> I think this logic in general will conflict between interrupt and poll
>>> mode. send_data is supposed to return -EBUSY only in polling mode and
>>> not in interrupt mode.
>> What is the recommended error code for this case? BTW,
On Wed, Dec 17, 2014 at 3:20 AM, Zefan Li wrote:
> On 2014/12/17 1:17, Vince Weaver wrote:
>> On Mon, 15 Dec 2014, Stephane Eranian wrote:
>>> On Mon, Dec 15, 2014 at 11:01 PM, Arnaldo Carvalho de Melo
>>> wrote:
>>
>>> fs is visible. The cgroup file system type is not there anymore. They are
On Tue, Jul 1, 2014 at 12:23 PM, Borislav Petkov wrote:
> Ok,
>
> the next version.
>
> Main changes from the last one are that we have a ce_ring now to which
> MCEs get logged in atomic context first and then, in process context,
> put into the CEC, just like this is done with the mce_ring.
>
>
On 2014/12/17 1:17, Vince Weaver wrote:
> On Mon, 15 Dec 2014, Stephane Eranian wrote:
>> On Mon, Dec 15, 2014 at 11:01 PM, Arnaldo Carvalho de Melo
>> wrote:
>
>> fs is visible. The cgroup file system type is not there anymore. They are
>> using
>> tmpfs which is not ideal to detect just
Hi Magnus and Geert,
On Wednesday 17 December 2014 10:30:33 Magnus Damm wrote:
> On Tue, Dec 16, 2014 at 9:40 PM, Geert Uytterhoeven wrote:
> > On Tue, Dec 16, 2014 at 12:46 PM, Magnus Damm wrote:
> >>> Could you please confirm that you've tested both CONFIG_PREEMPT_NONE and
> >>> CONFIG_PREEMPT
>
> On the Renesas R8A7791 SoC based boards there's MAX3355 USB OTG chip and
> mini-AB USB connector corresponding to USB port 0 driven either by EHCI/OHCI
> or Renesas USBHS gadget controller. And we'd like the host/gadget drivers to
> work based on the cable type connected. An 'extcon'
> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Dexuan Cui
> Sent: Wednesday, December 10, 2014 19:33 PM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; vkuzn...@redhat.com;
1 - 100 of 1196 matches
Mail list logo
