Since clk_register_clkdev() is exported for modules the caller should get a
pointer to the allocated resources. Otherwise the memory leak is guaranteed on
the ->remove() stage.
Cc: Tomeu Vizoso
Signed-off-by: Andy Shevchenko
---
arch/arm/mach-msm/clock-pcom.c | 9 +
arch/arm/ma
From: Borislav Petkov
Make it pass __func__ implicitly. Also, dump info about each replacing
we're doing. Fixup comments and style while at it.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/alternative.c | 41 +
1 file changed, 25 insertions(+), 16
From: Borislav Petkov
... and drop unfolded version. No need for ASM_NOP3 anymore either as
the alternatives do the proper padding at build time and insert proper
NOPs at boot time.
There should be no apparent operational change from this patch.
Signed-off-by: Borislav Petkov
---
arch/x86/inc
On Tue, Feb 3, 2015 at 8:05 AM, Mark Salyzyn wrote:
> Thanks for your response.
>
> On 01/30/2015 12:57 PM, Lukasz Stelmach wrote:
>>
>> On 28.01.2015 18:28, Mark Salyzyn wrote:
>>>
>>> - Precious little user-space content goes to kmsg (otherwise you
>>> can ask why is there a syslogd?), there is
Since clk_register_clkdev() is exported for modules the caller should get a
pointer to the allocated resources. Otherwise the memory leak is guaranteed on
the ->remove() stage.
The patch changes the prototype of the clk_register_clkdev() to return pointer
to the allocated resources. The caller sho
Quoting Stephen Rothwell (2015-02-02 21:31:40)
> Hi Mike,
>
> Today's linux-next merge of the clk tree got a conflict in
> arch/arm/mach-omap2/cclock3xxx_data.c between commit ca662ee7b8a8
> ("ARM: OMAP2+: Remove unused ti81xx platform init code") from the
> arm-soc tree and commit d6540b193719 ("
From: Markus Elfring
Date: Tue, 3 Feb 2015 19:21:21 +0100
The cpufreq_cooling_unregister() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfri
On Tue, Feb 3, 2015 at 1:06 PM, Josh Boyer wrote:
> On Tue, Feb 3, 2015 at 1:02 PM, Trond Myklebust
> wrote:
>> On Tue, Feb 3, 2015 at 12:40 PM, Josh Boyer
>> wrote:
>>> On Mon, Feb 2, 2015 at 8:43 AM, Trond Myklebust
>>> wrote:
On Mon, Feb 2, 2015 at 2:33 AM, Christoph Hellwig wrote:
>>
This patchset contains the initial common clock support for Broadcom's iProc
family of SoCs. The iProc clock architecture comprises of various PLLs, e.g.,
ARMPLL, GENPLL, LCPLL0, MIPIPLL, and etc. An onboard crystal serves as the
basic reference clock for these PLLs. Each PLL may have several leaf
Document the device tree binding for Broadcom iProc architecture based
clock controller
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
brcm,iproc-clocks.txt | 178 +
1 file changed, 178 insertions(+)
create mode 100644 brcm,iproc-clocks.t
Replace current device tree dummy clocks with real clock support for
Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus-clock.dtsi | 110 ---
arch/arm/boot/dts/bcm-cygnus.dtsi |2 +-
2 files changed, 86 i
The Broadcom Cygnus SoC is architected under the iProc architecture. It
has the following PLLs: ARMPLL, GENPLL, LCPLL0, MIPIPLL, all dervied
from an onboard crystal. Cygnus also has various ASIU clocks that are
derived directly from the onboard crystal.
Signed-off-by: Ray Jui
Reviewed-by: Scott B
This adds basic and generic support for various iProc PLLs and clocks
including the ARMPLL, GENPLL, LCPLL, MIPIPLL, and ASIU clocks.
SoCs under the iProc architecture can define their specific register
offsets and clock parameters for their PLL and clock controllers. These
parameters can be passed
The clock code under drivers/clk/bcm now contains code for both the
Broadcom mobile SoCs and the iProc SoCs. Change the the makefile
dependency to be under config flag CONFIG_ARCH_BCM that's enabled for
both families of SoCs
Signed-off-by: Ray Jui
---
drivers/clk/Makefile |2 +-
1 file chang
related to the proposed changes.
Patch was only compile tested for x86_64_defconfig + CONFIG_IRDA=m
CONFIG_VIA_FIR=m
Patch is against 3.19.0-rc7 (localversion-next = -next-20150203)
drivers/net/irda/via-ircc.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff
On 01/30/2015 09:23 PM, Guenter Roeck wrote:
Commit bcd022801ee5 ("MIPS: Fix COW D-cache aliasing on fork") replaced
the inline function copy_user_page for mips with an external reference,
but neglected to introduce the actual non-inline function. Restore it.
Fixes: bcd022801ee5 ("MIPS: Fix COW
On Tue, Feb 03, 2015 at 06:20:10PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20150202:
>
> The target-updates tree gained a conflict against Linus' tree.
>
> The clk tree gained conflicts against the arm-soc tree.
>
> Non-merge commits (relative to Linus' tree): 7173
> 7143 fi
BTW.,
if someone still likes my trivial approach and thinks the patches might
be usable because they contain just a few silly changes which might be
easily rebased onto future kernel versions, I suggest to get rid of the
new syscall and just use something like
#define AT_WIPE 0x200
From: Markus Elfring
Date: Tue, 3 Feb 2015 19:47:33 +0100
The of_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers
From: Mathieu Poirier
Function "get_logical_index()" is not available on arm64.
Instead of adding the function simply using "of_get_cpu_node()" and
comparing the return value with cpu handles yields the same
result.
Signed-off-by: Mathieu Poirier
---
drivers/coresight/of_coresight.c | 18 +
drivers/hwmon/tmp102.c:284:1: sparse: symbol 'tmp102_dev_pm_ops' was not
declared. Should it be static?
Signed-off-by: Fengguang Wu
---
tmp102.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 565df47..9da2735 100644
-
tree: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-next
head: 8170089e3c31b8b50ef5d2e21bdf20d7b7fa95b7
commit: 8170089e3c31b8b50ef5d2e21bdf20d7b7fa95b7 [19/19] hwmon: (tmp102) add
hibernation callbacks
reproduce:
# apt-get install sparse
git checkout 817008
Fixes a potential corruption with uninitialized stack memory in the seccomp
BPF sample program.
Reported-by: Robert Swiecki
Signed-off-by: Kees Cook
---
samples/seccomp/bpf-fancy.c | 4 +++-
samples/seccomp/bpf-helper.c | 5 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/s
For tip/timers/urgent.
Additional validation of adjtimex freq values to avoid
potential multiplication overflows were added in commit
5e5aeb4367b (time: adjtimex: Validate the ADJ_FREQUENCY values)
Unfortunately the patch used LONG_MAX/MIN instead of
LLONG_MAX/MIN, which was fine on 64bit systems
This patch fix the checkpatch.pl WARNING:
WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Bilel DRIRA
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 78 +-
1 file changed, 31 insertions(+), 47 deletions(-)
diff --git a/drivers/stag
Hi Guenter,
> The watchdog functionality in both chips is almost identical to NCT6779.
>
> Signed-off-by: Guenter Roeck
Patch has been added to linux-watchdog-next. Thanks for all the other reviews
again.
Kind regards,
Wim.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On Tue, 2015-02-03 at 19:16 +0100, Borislav Petkov wrote:
> Make it pass __func__ implicitly. Also, dump info about each replacing
> we're doing. Fixup comments and style while at it.
Perhaps s/DPRINTK/pr_debug/ and remove debug_alternative
while using the generic dynamic debug facilities is feasi
Hi Doug,
> On some dw_wdt implementations the "top" register may be initted to 0
> at bootup. In such a case, each "pat" of the watchdog will reset the
> timer to 0x. That's pretty short.
>
> The input clock of the wdt can be any of a wide range of values. On
> an rk3288 system, I've seen
From: Mathieu Poirier
Most CoreSight blocks are 64-bit ready. As such move configuration
entries from "arch/arm/Kconfig.config" to the driver's subdirectory
and source the newly created Kconfig from architecture specific
Kconfig.debug files.
Also fixing a couple of warnings generated by the 64-
Hi Doug,
> The dw_wdt_set_top() function takes in a value in seconds. In
> dw_wdt_open() we were calling it with a value that's supposed to
> represent the maximum value programmed into the "top" register with a
> comment saying that we were trying to set the watchdog to its maximum
> value. Ins
Hi Zubair,
> Here are two simple patches that add DT support to the jz4740 watchdog driver.
>
> Patches are based on 3.19-rc7. Quite disjoint and stay within jz4740
> so should apply easily on other trees.
>
> If you would like to have them rebased to a different tree, please tell.
>
> V3 Chang
On Tue, 2015-02-03 at 19:58 +0100, Bilel DRIRA wrote:
> This patch fix the checkpatch.pl WARNING:
[]
> diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
[]
> @@ -1963,11 +1948,10 @@ static irqreturn_t ft1000_interrupt(int irq, void
Currently gic_raise_softirq() is locked using upon irq_controller_lock.
This lock is primarily used to make register read-modify-write sequences
atomic but gic_raise_softirq() uses it instead to ensure that the
big.LITTLE migration logic can figure out when it is safe to migrate
interrupts between
This patchset modifies the GIC driver to allow it, on supported
platforms, to route IPI interrupts to FIQ. It then uses this
feature to implement arch_trigger_all_cpu_backtrace for arm.
In order to neatly (and safely) bring in the changes for the arm
we also make the sched_clock implementation NMI-
It is currently possible for FIQ handlers to re-enter gic_raise_softirq()
and lock up.
gic_raise_softirq()
lock(x);
-~-> FIQ
handle_fiq()
gic_raise_softirq()
lock(x); <-- Lockup
arch/arm/ uses IPIs to implement arch_irq_work_raise(), th
On 02/03/2015 01:42 PM, Guenter Roeck wrote:
> On Tue, Feb 03, 2015 at 06:20:10PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20150202:
>>
>> The target-updates tree gained a conflict against Linus' tree.
>>
>> The clk tree gained conflicts against the arm-soc tree.
>>
>> Non-merg
On Tue, Jan 27, 2015 at 04:12:04PM +, Matt Fleming wrote:
> From: Matt Fleming
>
> Andy pointed out that if an NMI or MCE is received while we're in the
> middle of an EFI mixed mode call a triple fault will occur. This can
> happen, for example, when issuing an EFI mixed mode call while runn
On 02/02, Rik van Riel wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/02/2015 02:21 PM, Oleg Nesterov wrote:
> > I'll try to read this patch tomorrow. Too late for me.
> >
> > I think it is fine, but
> >
> > On 02/02, r...@redhat.com wrote:
> >>
> >> This also fixes the lazy F
Currently it is not possible to exploit FIQ for systems with a GIC, even if
the systems are otherwise capable of it. This patch makes it possible
for IPIs to be delivered using FIQ.
To do so it modifies the register state so that normal interrupts are
placed in group 1 and specific IPIs are placed
Currently there is a quite a pile of code sitting in
arch/x86/kernel/apic/hw_nmi.c to support safe all-cpu backtracing from NMI.
The code is inaccessible to backtrace implementations for other
architectures, which is a shame because they would probably like to be
safe too.
Copy this code into prin
Hello,
[added some more context again]
On Tue, Feb 03, 2015 at 03:14:43PM +, David Howells wrote:
> > > - *p |= mask;
> > > + if ((*p & mask) == 0)
> > > + *p |= mask;
> > Care to fix the double space here while touching the code?
> >
> > I think the more natural check
Much of the code sitting in arch/x86/kernel/apic/hw_nmi.c to support safe
all-cpu backtracing from NMI has been copied to printk.c to make it
accessible to other architectures.
Port the x86 NMI backtrace to the generic code.
Signed-off-by: Daniel Thompson
Cc: Steven Rostedt
Cc: Thomas Gleixner
Replicate the x86 code to trigger a backtrace using an NMI and hook
it up to IPI on ARM.
The code differs slightly from the code on x86 because, on ARM, we do
now know at compile time whether a platform is capable of supporting FIQ.
We must avoid using an IPI to request a backtrace from the CPU on
On 02/03/2015 12:13 PM, Stefan Seyfried wrote:
Am 29.01.2015 um 13:17 schrieb Ming Lei:
This reverts commit 76d697d10769048e5721510100bf3a9413a56385.
The commit 76d697d10769048 causes general protection fault
reported from Bart Van Assche:
https://lkml.org/lkml/2015/1/28/334
I bisect
Hi,
tested next-20150202. System boots, but graphic output is broken (empty black
screen).
Booted five times the same kernel, always got the same result. The system works
with 3.19-rc7.
This is the first warning in the log:
WARNING: CPU: 0 PID: 855 at drivers/gpu/drm/i915/intel_uncore.c:169
В Tue, 3 Feb 2015 11:52:50 +
Mark Rutland пишет:
> On Mon, Feb 02, 2015 at 09:48:50PM +, Roman Volkov wrote:
> > This header file designed to be similar to other glue layers found
> > for i8042. The difference is that interrupt numbers, device address,
> > and other information should be
On Tue, Feb 03, 2015 at 10:32:11AM -0700, Lina Iyer wrote:
> >
> >Well, I am not convinced drivers really need to be aware of these trip
> >types. Which kind of drivers are we talking? Thermal zone drivers?
> >cooling device drivers?
>
> I am sorry, I am missing the point here. The Tz driver is
Am 29.01.2015 um 13:17 schrieb Ming Lei:
> This reverts commit 76d697d10769048e5721510100bf3a9413a56385.
>
> The commit 76d697d10769048 causes general protection fault
> reported from Bart Van Assche:
>
> https://lkml.org/lkml/2015/1/28/334
I bisected the "unplugging my USB stick crashes t
From: Markus Elfring
Date: Tue, 3 Feb 2015 20:12:25 +0100
The functions cpsw_ale_destroy() and of_dev_put() test whether their argument
is NULL and then return immediately. Thus the test around the call
is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Mark
2015-02-03 19:56 GMT+01:00 Kees Cook :
> Fixes a potential corruption with uninitialized stack memory in the seccomp
> BPF sample program.
>
> Reported-by: Robert Swiecki
> Signed-off-by: Kees Cook
> ---
> samples/seccomp/bpf-fancy.c | 4 +++-
> samples/seccomp/bpf-helper.c | 5 +
> 2 file
On Tue, Feb 3, 2015 at 9:34 AM, Joerg Roedel wrote:
>
> Hmm, have you seen spurious wakeups happening? The wakeup only comes
> from put_device_state() and only when the reference count goes to zero.
Even if that were true - and it isn't - the patch in question making
it simpler and more robust, r
On Tue, Feb 03, 2015 at 10:14:32PM +0300, Roman Volkov wrote:
> В Tue, 3 Feb 2015 11:52:50 +
> Mark Rutland пишет:
>
> > On Mon, Feb 02, 2015 at 09:48:50PM +, Roman Volkov wrote:
> > > This header file designed to be similar to other glue layers found
> > > for i8042. The difference is th
I am announcing the release of the Linux 3.13.11-ckt15 kernel.
The updated 3.13.y-ckt tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y
and can be browsed at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog
The diff from v3.13.1
On Tue, Feb 03, 2015 at 11:24:45AM +0200, Ivan T. Ivanov wrote:
>
> Hi Eduardo,
>
> On Mon, 2015-02-02 at 14:14 -0400, Eduardo Valentin wrote:
> > Ivan,
> >
> > On Mon, Feb 02, 2015 at 05:19:30PM +0200, Ivan T. Ivanov wrote:
> > > Add support for the temperature alarm peripheral found inside
> >
Hi Linus,
Unfortunately the hctx/ctx lifetime fix from last pull had some issues.
This pull request contains a revert of the problematic commit, and a
proper rewrite of it. The rewrite has been tested by the users
complaining about the regression, and it works fine now. Additionally,
I've run test
On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote:
> > On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 February 2015
On 2/3/2015 9:40 AM, Dmitry Torokhov wrote:
> Hi Ray,
>
> On Mon, Feb 02, 2015 at 06:01:33PM -0800, Ray Jui wrote:
>> This adds the initial driver support for the Broadcom Cygnus IOMUX
>> controller. The Cygnus IOMUX controller supports group based mux
>> configuration but allows certain pins to
Hi Benjamin,
> Slot 0 is released correclty, but when we look for Contact ID 2, the slot
> 0 is then picked up again because it is marked as inactive (trackingID < 0).
>
> This is wrong, and we should not reuse a slot in the same frame.
> The test should also check for input_mt_is_used().
Good c
On Tue, 3 Feb 2015 16:47:48 +
Mark Brown wrote:
> On Sat, Jan 24, 2015 at 08:30:27AM +0100, Jean-Francois Moine wrote:
> > Mark Brown wrote:
> > > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote:
>
> > > > The simple card builder, 'dt-card' (maybe a better name would hav
On Tue, Feb 03, 2015 at 11:38:16AM +, Mark Rutland wrote:
> On Mon, Feb 02, 2015 at 09:48:46PM +, Roman Volkov wrote:
> > Documentation for 'intel,8042' DT compatible node.
> >
> > Signed-off-by: Tony Prisk
> > Signed-off-by: Roman Volkov
> > ---
> > .../devicetree/bindings/input/intel-
On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote:
> On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> > On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote:
> > > On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Tue, Feb 03, 2015 at
>> Fixes a potential corruption with uninitialized stack memory in the seccomp
>> BPF sample program.
>>
>> Reported-by: Robert Swiecki
>> Signed-off-by: Kees Cook
>> ---
>> samples/seccomp/bpf-fancy.c | 4 +++-
>> samples/seccomp/bpf-helper.c | 5 +
>> 2 files changed, 8 insertions(+), 1 d
On 02/03/2015 10:16 AM, Borislav Petkov wrote:
From: Borislav Petkov
Alternatives allow now for empty old instruction. In this case we go
and pad the space with NOPs at assembly time. However, there are the
optimal, longer NOPs which should be used. Do that at patching time.
Signed-off-by: Bor
On Tue, Feb 03, 2015 at 12:48:49AM +0300, Roman Volkov wrote:
> Use platform_device_probe() instead of platform_create_bundle() when
> compiled with DT support, since the latter function is not suitable for
> handling the OF device tree.
>
> The order of initialization is changed, since i8042_plat
On Tue, 2015-02-03 at 09:54 -0800, Jason Low wrote:
> On Tue, 2015-02-03 at 09:16 -0800, Tim Chen wrote:
> > > > >
> > > > > + if (READ_ONCE(sem->owner))
> > > > > + return true; /* new owner, continue spinning */
> > > > > +
> > > >
> > > > Do you have some comparison data of wh
On Tue, Feb 03, 2015 at 10:57:38AM -0800, John Stultz wrote:
> Unfortunately the patch used LONG_MAX/MIN instead of
> LLONG_MAX/MIN, which was fine on 64bit systems, but being
> much smaller on 32bit systems caused false positives
> resulting in most direct frequency adjustments to fail w/
> EINVAL
On Tue, 3 Feb 2015, Casey Schaufler wrote:
> > (I wasn't going to ask bc I assumed not, but heck maybe you're bored
> > on a desert island or snowed in and just looking for an excuse to hack :)
>
> Not at all bored, but I think this could be important.
Ok here is a draft of a patch that follows t
On Fri, Jan 30, 2015 at 10:56:28AM +0530, Vignesh R wrote:
>
>
> On Wednesday 07 January 2015 11:19 AM, Vignesh R wrote:
> > From: Brad Griffis
> >
> > TSC interrupt handler had udelay to avoid reporting of false pen-up
> > interrupt to user space. This patch implements workaround suggesting in
On Tue, Feb 03, 2015 at 01:35:25PM -0600, Felipe Balbi wrote:
> On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote:
> > On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> > > On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 February 2015 16:43:45 Fel
On Tue, Feb 03, 2015 at 11:36:34AM -0800, Andy Lutomirski wrote:
> I'm a bit confused here. Shouldn't NOPs after a non-NOP in the old
> instruction also be optimized?
Yes, they should! Good point.
Thanks, will fix.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
On 02/03/2015 10:16 AM, Borislav Petkov wrote:
From: Borislav Petkov
... now that we have it.
Hallelujah!
Acked-by: Andy Lutomirski
Cc: Richard Weinberger
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/barrier.h | 6 ++
arch/x86/um/asm/barrier.h | 4 ++--
2 files
On Tuesday 03 February 2015 20:35:25 Felipe Balbi wrote:
> On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote:
> > On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> > > On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 February 2015 16:43:45 Felipe B
Hi,
Commit c6e5e9fbc3ea1c1a5648a3498d085fc3978df2d4 breaks the following make
invocation (-j, -C, O=, LDFLAGS=, and build directory prefix stripped to
simplify report):
make ARCH=x86_64 CROSS_COMPILE= EXTRA_CFLAGS=
config/Makefile:128: The path 'python-config' is not executable.
config/Makefile:3
On Tue, Feb 03, 2015 at 11:29:36AM -0800, Ray Jui wrote:
> On 2/3/2015 9:40 AM, Dmitry Torokhov wrote:
> > On Mon, Feb 02, 2015 at 06:01:33PM -0800, Ray Jui wrote:
> >> +
> >> +/*
> >> + * List of pins in Cygnus
> >> + */
> >> +static struct cygnus_pin cygnus_pins[] = {
> >
> > const?
> >
> I can
Hi,
On Tue, Feb 03, 2015 at 08:57:11PM +0100, Pali Rohár wrote:
> > > > > > > > f_phonet's ->set_alt() method will call
> > > > > > > > usb_ep_disable() potentially on an endpoint which
> > > > > > > > is already disabled. That's something the
> > > > > > > > gadget/function driver must guarantee
On 3 Feb 2015, Myron Stowe uttered the following:
> As expressed above, I believe this device is non-conformant. This could be
> validated by instrumenting the kernel's sizing code in '__pci_read_base()';
> specifically the initial 'pci_read_config_dword()'s of 'l' and 'sz'.
>
> Whereas we have b
On Tue, Feb 03, 2015 at 05:36:59PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 11:22:01 Rob Clark wrote:
> > On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > > I agree for the case you are describing here. From what I understood
> > > from Rob was that he is looking at somet
On Tuesday 03 February 2015 20:51:34 Felipe Balbi wrote:
> On Tue, Feb 03, 2015 at 01:35:25PM -0600, Felipe Balbi wrote:
> > On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote:
> > > On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote:
> > > > On Tue, Feb 03, 2015 at 05:17:28PM +0100, P
ined comment string if that is still valid now.
>>
>> Patch was only compile tested for x86_64_defconfig + CONFIG_STAGING=y
>> CONFIG_COMEDI=m, COMEDI_ISA_DRIVERS=y, CONFIG_COMEDI_DT282X=m
>>
>> Patch is against 3.0.19-rc7 (localversion = -next-20150203)
>>
>
Ok,thank you, I will do that and resend the patch again.
On Tue, Feb 03, 2015 at 11:05:08AM -0800, Joe Perches wrote:
> On Tue, 2015-02-03 at 19:58 +0100, Bilel DRIRA wrote:
> > This patch fix the checkpatch.pl WARNING:
> []
> > diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
> > b/
se it landed in
today's linux-next (ie, next-20150203) and depends on ARCH_SPRD.
ARCH_SPRD is not yet included in linux-next. Since there was a patch
submitted on lkml recently to add that symbol that's not a big deal.
(That might change if that symbol doesn't make it into v3.20-rc[12
ster
>> >
>> > That should also fetch the next- tag.
>>
>> For current -next this is OK.
>> Sometimes I needed to test against a specific next-version.
>> Any idea?
>
> $ git clone next
> $ cd next
> $ git fetch next-
> $ git check
On Tue, Feb 03, 2015 at 12:35:34PM -0500, Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:58 AM, Russell King - ARM Linux
> wrote:
> >
> > Okay, but switching contexts is not something which the DMA API has
> > any knowledge of (so it can't know which context to associate with
> > which mapping.) Wh
On Tue, Feb 03, 2015 at 11:55:11AM -0800, Andy Lutomirski wrote:
> On 02/03/2015 10:16 AM, Borislav Petkov wrote:
> >From: Borislav Petkov
> >
> >... now that we have it.
>
> Hallelujah!
>
> Acked-by: Andy Lutomirski
Haha, yeah.
Btw, the uml bits are going away because we realized we don't ne
On Tue, Feb 03, 2015 at 02:17:49PM +, Mark Rutland wrote:
> On Mon, Feb 02, 2015 at 12:45:42PM +, Hanjun Guo wrote:
> > Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
> > from the GICC Structure introduced by ACPI 5.1.
> >
> > MPIDR is the CPU hardware ID as local
Hi Changman,
Good idea!
Change log from v2:
o add sysfs to change the # of sections for trimming.
Change log from v1:
o add description
o change the # of batched segments suggested by Chao
o make consistent for # of batched segments
This patch introduces a batched trimming feature, which s
Peter,
I am getting more confused when I re-read your email today ;) see below.
Btw, do you agree with 1/1? Can you ack/nack it?
On 02/02, Peter Zijlstra wrote:
>
> On Mon, Feb 02, 2015 at 03:05:15PM +0100, Oleg Nesterov wrote:
>
> > And another question. Lets forget about this ->mm check. I sim
On Tue, Feb 3, 2015 at 11:45 AM, Christoph Lameter wrote:
> On Tue, 3 Feb 2015, Casey Schaufler wrote:
>
>> > (I wasn't going to ask bc I assumed not, but heck maybe you're bored
>> > on a desert island or snowed in and just looking for an excuse to hack :)
>>
>> Not at all bored, but I think this
Your commit 9d9c867684ec ("ARC: [axs10x] Add support for AXS10x software
development platform") is included in today's linux-next (ie,
next-20150203). In noticed because a script I use to check linux-next
spotted a problem with it.
That commit adds a select for the Kconfig symbol D
On Tue, 2015-02-03 at 21:05 +0100, bill wrote:
> Ok,thank you, I will do that and resend the patch again.
I wouldn't.
It's probably better as a separate patch anyway.
btw: please don't top post.
cheers, Joe
> On Tue, Feb 03, 2015 at 11:05:08AM -0800, Joe Perches wrote:
> > On Tue, 2015-02-03 at
Vineet,
On Tue, 2015-02-03 at 21:13 +0100, Paul Bolle wrote:
> Your commit 9d9c867684ec ("ARC: [axs10x] Add support for AXS10x software
> development platform") is included in today's linux-next (ie,
> next-20150203). In noticed because a script I use to check linux-next
On Wed, 4 Feb 2015, Minchan Kim wrote:
> > > This is a result of allowing something external (process B) be able to
> > > clear hwm so that you never knew the value went to 100MB. That's the
> > > definition of a race, I don't know how to explain it any better and making
> > > any connection betw
On 2/3/2015 12:00 PM, Dmitry Torokhov wrote:
> On Tue, Feb 03, 2015 at 11:29:36AM -0800, Ray Jui wrote:
>> On 2/3/2015 9:40 AM, Dmitry Torokhov wrote:
>>> On Mon, Feb 02, 2015 at 06:01:33PM -0800, Ray Jui wrote:
+
+/*
+ * List of pins in Cygnus
+ */
+static struct cygnus_
Em Wed, 28 Jan 2015 16:11:22 +0100
Luis de Bethencourt escreveu:
Please provide some description
> Signed-off-by: Luis de Bethencourt
Also, if you're touching on those printks, you should be fixing the
scripts/checkpatch.pl warnings for that too:
WARNING: line over 80 characters
#28: FILE: dr
next-20150107
>>> >
>>> > Just do
>>> >
>>> > $ git pull
>>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>>> >
>>> > That should also fetch the next- tag.
>>>
>>> For
On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> Hi,
>
> tested next-20150202. System boots, but graphic output is broken (empty black
> screen).
> Booted five times the same kernel, always got the same result. The system
> works with 3.19-rc7.
Those two warnings are more or
This patch fix checkpatch.pl WARNING:
WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Bilel DRIRA
---
drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 73 +-
1 file changed, 29 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/
On Tue, Feb 03, 2015 at 12:02:13PM -0700, mathieu.poir...@linaro.org wrote:
> diff --git a/drivers/coresight/Kconfig b/drivers/coresight/Kconfig
> new file mode 100644
> index ..271fad830ae4
> --- /dev/null
> +++ b/drivers/coresight/Kconfig
> @@ -0,0 +1,60 @@
> +#
> +# Coresight configu
e commit be46ac86a81b ("x86/raid6: correctly check for
assembler capabilities") in today's linux-next (ie, next-20150203). I
noticed because a script I use to check linux-next spotted a potential
problem with it.
> ---
> arch/x86/Makefile |1 +
> lib/raid6/algo
Hi,
Please consider adding subsystem specific mailing list(s) in the MAINTAINERS
file for the performance events and tracing subsystems. I am interested in
following (and contributing to when the opportunity arises) the development of
these subsystems; filtering and archiving the whole of LKML in
501 - 600 of 960 matches
Mail list logo
