Il 05/09/2014 17:14, Thomas Gleixner ha scritto:
> So that means the code is correct. Now where is the bug?
In kernel/time/timekeeping.c?
We know that we should have
base_mono = wall_to_monotonic + xtime_sec
Instead it is
base_mono = wall_to_monotonic +
Arnd, Olof, Kevin,
This pull-request is focused on the work that Maxime did for migrating our timer
(PIT) to the clocksource sub-system. A big cleanup happened which allows us to
be even closer to the point when we have only the bare minimum in our formerly
crowded mach-at91 directory.
This
On architectures that use percpu-vm, the percpu region is not guaranteed
to be contiguous in physical space. However, fs/proc/vmcore.c expects
all ELF notes to be contiguous. If the ELF note happens to occupy
two non-adjacent physical pages, part of the note may be read from an
incorrect memory
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote:
> I would prefer a interface more like recv() where I can specify the
> flag if I want blocking behavior for this read or not. Let me explain
> why:
>
> In a VLDB like workload this would enable me to lower the latency of
> common
On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote:
>> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */
>
> This is just another representation of the following code which isn't
> particularly useful. Wouldn't it be better if the comment actually
> explains why this might not be
I would prefer a interface more like recv() where I can specify the
flag if I want blocking behavior for this read or not. Let me explain
why:
In a VLDB like workload this would enable me to lower the latency of
common fast requests and. By fast requests I mean ones that do not
require much data,
On Friday 05 September 2014 15:22:46 Mark Rutland wrote:
>
> > A common pattern these days is to do dependencies like
> >
> > arch/*/Kconfig:
> > config ARCH_FOO
> > bool "Enable support for Foo platform"
> > help
> > ...
> >
> >
> > drivers/*/Kconfig
> > config
Hello,
I noticed, with next/master tree, this lockdep splat and at least I could not
find any discussion about this by googling:
[ 33.105722] =
[ 33.105722] [ INFO: possible irq lock inversion dependency detected ]
[ 33.105724]
Hi Mikulas,
On 09/05/2014 06:01 PM, Mikulas Patocka wrote:
This patch fixes false positive kmemcheck warning in bpf.
When we try to write the variable len, the compiler generates a code that
reads the 32-bit word, modifies the bits belonging to "len" and writes the
32-bit word back. The
On Fri, Sep 5, 2014 at 9:01 AM, Mikulas Patocka wrote:
> This patch fixes false positive kmemcheck warning in bpf.
>
> When we try to write the variable len, the compiler generates a code that
> reads the 32-bit word, modifies the bits belonging to "len" and writes the
> 32-bit word back. The
On 09/05/2014 08:37 AM, David Laight wrote:
> From: Peter Hurley
>> On 09/05/2014 04:30 AM, David Laight wrote:
>>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
>>> It does this because of the more limited range of the offsets for the 16bit
>>> access.
>>> OTOH I
This patch fixes kmemcheck warning in switch_names. The function
switch_names swaps inline names of two dentries. It swaps full arrays
d_iname, no matter how many bytes are really used by the strings. Reading
data beyond string ends results in kmemcheck warning.
We fix the bug by marking both
On 28/08/14 09:59, Suravee Suthikulpanit wrote:
>
>
> On 08/15/2014 09:03 AM, Marc Zyngier wrote:
>>> +
>>> +static struct irq_chip gicv2m_chip;
>>> +
>>> +#ifdef CONFIG_OF
>>
>> Is there any reason why this should be guarded by CONFIG_OF? Surely the
>> v2m capability should only be enabled if
On Fri, Sep 5, 2014 at 6:38 PM, Johan Hovold wrote:
> On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
>
>> +static int dln2_do_remove(struct dln2_gpio *dln2)
>> +{
>> + /* When removing the DLN2 USB device, gpiochip_remove may fail
>> + * due to i2c drivers holding a
On Fri, Sep 05, 2014 at 07:11:31AM +, li.xi...@freescale.com wrote:
> Hi,
>
> Ping :)
>
Wim usually picks up patches shortly before the next release window opens.
It is in my watchdog-next branch, so it is not forgotten. I'll send a pull
request to Wim after -rc5.
Wim, I am wondering -
On Fri, Sep 05, 2014 at 12:02:19PM -0400, Jeff Moyer wrote:
> > One further consideration would be to finally implement real buffered
> > I/O in kernel space by something like the above and offloading to
> > workqueues in kernelspace. I think our workqueues now are way better
> > than any
Christoph Hellwig writes:
> On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
>> I suggest you look at the recent fincore debate. It did not progress much
>> the last time because the author wanted to push a lot of functionality in
>> there where as reviewers felt it should start
This patch fixes false positive kmemcheck warning in bpf.
When we try to write the variable len, the compiler generates a code that
reads the 32-bit word, modifies the bits belonging to "len" and writes the
32-bit word back. The reading of the word results in kmemcheck warning due
to reading
Variable cmd_name must be initialised as variable name is.
Signed-off-by: Dmitry Voytik
---
drivers/staging/android/binder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index 4f34dc0..93b067f 100644
---
Arnd, Olof, Kevin,
Little pull-request for fixing CCF conversion done during 3.17.
The use of at91sam9g20 proper compatibility string is useful when booting
without U-Boot (this is why we discover it now).
Thanks, best regards,
The following changes since commit
On Fri, Sep 05, 2014 at 11:20:43PM +0900, Kamezawa Hiroyuki wrote:
> Basically, I don't like OOM Kill. Anyone don't like it, I think.
>
> In recent container use, application may be build as "stateless" and
> kill-and-respawn may not be problematic, but I think killing "a" process
> by oom-kill
Am 05.09.2014 17:20, schrieb Kumar Gala:
> On Sep 5, 2014, at 9:26 AM, Andreas Färber wrote:
>> Am 03.09.2014 18:50, schrieb Georgi Djakov:
>>> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
>>> b/arch/arm/boot/dts/qcom-apq8084.dtsi
>>> index 21d01e5..1f130bc 100644
>>> ---
Hi
On 09/05/2014 05:26 PM, Andreas Färber wrote:
<...>
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
I see that you've used GPIO_ACTIVE_* above. Is the trailing zero here
possibly IRQ_TYPE_NONE?
Yes, it is. Will update
On Thu, Sep 04, 2014 at 03:39:52PM +0100, Lee Jones wrote:
Some text may be useful here.
> Signed-off-by: David Paris
> Signed-off-by: Lee Jones
> ---
> drivers/watchdog/Kconfig | 16 +++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/st_wdt.c | 314
>
On Fri, Sep 05, 2014 at 10:47:01AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
> > +static int st_dwc3_remove_child(struct device *dev, void *c)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > +
> > +
On Fri, 2014-09-05 at 08:41 -0700, H. Peter Anvin wrote:
> On 09/05/2014 08:22 AM, Toshi Kani wrote:
> > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote:
> >> On 09/05/2014 07:00 AM, Toshi Kani wrote:
> >>>
> >>> That's a fine idea, but as Ingo also suggested, I am going to disable
> >>>
On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
> I suggest you look at the recent fincore debate. It did not progress much
> the last time because the author wanted to push a lot of functionality in
> there where as reviewers felt it should start simple. The simple case is
> likely a
On 09/05/2014 01:17 PM, Geert Uytterhoeven wrote:
Add RCAN clock support to the R-Car generation 2 CPG driver. This clock
gets
derived from the USB_EXTAL clock by dividing it by 6. The layout of
RCANCKCR
register is close to those of the clocks supported by the 'clk-div6'
driver
but has no
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
> +static int st_dwc3_remove_child(struct device *dev, void *c)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + of_device_unregister(pdev);
> +
> + return 0;
> +}
> +
> +static int
Em Sat, Sep 06, 2014 at 12:16:40AM +0900, Namhyung Kim escreveu:
> Hi Adrian and Arnaldo,
>
> 2014-09-05 (금), 11:11 -0300, Arnaldo Carvalho de Melo:
> > Em Fri, Sep 05, 2014 at 10:22:40AM +0300, Adrian Hunter escreveu:
> > > On 09/05/2014 07:59 AM, Namhyung Kim wrote:
> > > > +++
(Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead)
On 05 Sep 04:23 PM, klightsp...@killerwolves.net wrote:
> The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC
> (strength = 4), while the pxa3xx NAND driver by default uses
> Hamming ECC (strength = 1).
>
On 09/05/2014 08:31 AM, Peter Hurley wrote:
>
> Which is a bit ironic because I remember when Digital had a team
> working on emulating native x86 apps on Alpha/NT.
>
Right, because the x86 architecture was obsolete and would never scale...
-hpa
--
To unsubscribe from this list: send
On 05/09/14 15:17, Jens Axboe wrote:
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.
Just "piping up"
On 09/05/2014 08:22 AM, Toshi Kani wrote:
> On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote:
>> On 09/05/2014 07:00 AM, Toshi Kani wrote:
>>>
>>> That's a fine idea, but as Ingo also suggested, I am going to disable
>>> this feature on all Pentium 4 models. That should give us a safety
On Fri, Sep 5, 2014 at 8:16 AM, Peter Zijlstra wrote:
>
> How horrible is the below patch (performance wise). It does pretty much
> the same thing except that percpu_rw_semaphore is a lot saner, its
> read side performance should be minimal in the absence of writes.
Ugh. Why do any locking at
On Fri, 5 Sep 2014, Xiubo Li wrote:
> Since the Flextimer device will be implemented in BE mode on
> LS1 SoC, and in LE mode on Vybrid, LS2 SoCs, so here we need
> the endianness judgment before doing the mmio.
WTF? I explained you in great length HOW you should solve that, but
you just ignore
On Fri, Sep 5, 2014 at 7:38 PM, Nathan Fontenot
wrote:
> On 09/05/2014 04:16 AM, bharata@gmail.com wrote:
>> From: Bharata B Rao
>>
>> - ibm,rtas-configure-connector should treat the RTAS data as big endian.
>> - Treat ibm,ppc-interrupt-server#s as big-endian when setting
>>
On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
> +static int dln2_do_remove(struct dln2_gpio *dln2)
> +{
> + /* When removing the DLN2 USB device, gpiochip_remove may fail
> + * due to i2c drivers holding a GPIO pin. However, the i2c bus
> + * will eventually be
On Fri 05-09-14 10:47:23, Johannes Weiner wrote:
> On Fri, Sep 05, 2014 at 11:25:37AM +0200, Michal Hocko wrote:
> > @@ -900,10 +900,10 @@ void lru_add_drain_all(void)
> > * grabbed the page via the LRU. If it did, give up:
> > shrink_inactive_list()
> > * will free it.
> > */
> > -void
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 +++
1
This patch adds the new dwc3-st.c glue driver found on
STMicroelectronics stih407 consumer electronics SoC's into the STI
arch section of the maintainers file.
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
drivers/usb/dwc3/Kconfig | 9
This series adds support for the ST glue logic which wraps the DWC3 controller
on STiH407 SoC family chipsets.
Changes since v5
- Use of_platform_depopulate
Changes since v4
- Fix bug with setting bits in usb control register
- Remove superflous '\n'
- Change default Kconfig to make default
This patch introduces a new default FIQ handler that is structured in a
similar way to the existing ARM exception handler and result in the FIQ
being handled by C code running on the SVC stack (despite this code run
in the FIQ handler is subject to severe limitations with respect to
locking making
This patch provides support for arm's newly added IPI FIQ. It works
by placing all interrupt sources *except* IPI FIQ in group 1 and
then flips a configuration bit in the GIC such that group 1
interrupts use IRQ and group 0 interrupts use FIQ.
All GIC hardware except GICv1-without-TrustZone
Drivers that are shared between arm and arm64 and which employ
FIQ on arm cannot include asm/fiq.h without #ifdef'ing. This patch
introduces a dummy version of asm/fiq.h to arm64 to avoid this.
Signed-off-by: Daniel Thompson
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/include/asm/fiq.h
From: Russell King
Add basic infrastructure for triggering a backtrace of other CPUs
via an IPI, preferably at FIQ level. It is intended that this shall
be used for cases where we have detected that something has already
failed in the kernel.
Signed-off-by: Russell King
---
From: Russell King
do_unexp_fiq() has never been called by any code in the last 10 years,
it's about time it was removed!
Signed-off-by: Russell King
---
arch/arm/kernel/traps.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index
This patchset implements arch_trigger_all_cpu_backtrace for arm.
Non-maskable signalling relies on the kernel being able to access FIQ
and therefore, for devices that implement TrustZone, it will work only on
systems that boot the kernel in secure mode.
Tested on Freescale iMX.6 (both via
On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote:
> On 09/05/2014 07:00 AM, Toshi Kani wrote:
> >
> > That's a fine idea, but as Ingo also suggested, I am going to disable
> > this feature on all Pentium 4 models. That should give us a safety
> > margin. Using slot 4 has a benefit that
On 05/09/2014 17:26, Nicolas Ferre :
> On 05/09/2014 16:15, Alexandre Belloni :
>> Actually register clocks from device tree when using the common clock
>> framework.
>>
>> Signed-off-by: Alexandre Belloni
>
> Indeed, thanks: I'll queue it in at91-3.18-fixes.
s/18/17/
Sorry.
>
> Acked-by:
On 09/05/2014 05:04 PM, Krzysztof Kozlowski wrote:
If dma_async_device_register() returns error and probe should clean up
and return error, a NULL pointer exception happens because of
dereference of not allocated channel thread:
[...]
Signed-off-by: Krzysztof Kozlowski
Reviewed-by:
On 09/04/2014 10:08 PM, H. Peter Anvin wrote:
> On 09/04/2014 05:59 PM, Peter Hurley wrote:
>> I have no idea how prevalent the ev56 is compared to the ev5.
>> Still we're talking about a chip that came out in 1996.
>
> Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
> were
On 09/05/2014 05:04 PM, Krzysztof Kozlowski wrote:
[...]
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lars-Peter Clausen
--
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
On 09/05/2014 05:04 PM, Krzysztof Kozlowski wrote:
Do not dereference the 'struct pl330_thread *thrd' before the check for
non-NULL value.
This fixes following warning:
drivers/dma/pl330.c:1376 pl330_submit_req() warn: variable dereferenced before
check 'thrd' (see line 1367)
I think we can
On Thu, Sep 04, 2014 at 03:39:51PM +0100, Lee Jones wrote:
> Signed-off-by: David Paris
> Signed-off-by: Lee Jones
You might want to copy the devicetree mailing list for bindings approval.
> ---
> .../devicetree/bindings/watchdog/st-lpc-wdt.txt| 27
> ++
> 1 file
On 05/09/2014 16:45, Alexandre Belloni :
> The atmel,clk-divisors property is taking 4 divisors, if less are
> provided, the clock registration will fail.
>
> Signed-off-by: Alexandre Belloni
Acked-by: Nicolas Ferre
Stacked on at91-3.17-fixes.
> ---
> arch/arm/boot/dts/at91rm9200.dtsi | 2
On 05/09/2014 16:15, Alexandre Belloni :
> Actually register clocks from device tree when using the common clock
> framework.
>
> Signed-off-by: Alexandre Belloni
Indeed, thanks: I'll queue it in at91-3.18-fixes.
Acked-by: Nicolas Ferre
> ---
> arch/arm/mach-at91/board-dt-rm9200.c | 11
On 09/05/14 15:56, Douglas Gilbert wrote:
With scsi-mq I think many LLDs probably have a new
race possibility between a surprise rmmod of the LLD
and another thread presenting a new command at about
the same time (or another thread's command completing
around that time). Does anything above the
Hi Jeff,
I don't know if we can keep audit_inode() in do_last(). I've tried
this but found
the only way to enable both write() and create() is moving it to lookup_open().
I know this is not good, but I think we have no choice.
The current patch really miss the ROFS condition as you said. How
On 09/05/2014 05:06 PM, Krzysztof Kozlowski wrote:
[...]
@@ -2168,11 +2199,23 @@ static void pl330_issue_pending(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
unsigned long flags;
+ bool power_up;
spin_lock_irqsave(>lock, flags);
+
On 01/09/2014 23:29, Gaël PORTAY :
> The at91sam9g20 SOC uses its own pllb implementation which is different
> from the one inherited from at91sam9260 SOC.
>
> Signed-off-by: Gaël PORTAY
Acked-by: Nicolas Ferre
Stacked on at91-3.17-fixes. Thanks!
> ---
> arch/arm/boot/dts/at91sam9g20.dtsi |
On Fri, Sep 5, 2014 at 4:25 PM, Liang, Kan wrote:
> Hi Peter and all,
>
> Did you get a chance to review these patches?
> Zheng is away. Should I re-send the patches?
>
Please resubmit rebased to tip.git and I'll take another look.
> Thanks,
> Kan
>
>>
>> For many profiling tasks we need the
The current implementation of gpiochip_remove() does not check to see
if the GPIO pins are busy before removing the associated irqchip and
this is causing the following warning:
WARNING: CPU: 3 PID: 553 at fs/proc/generic.c:521
remove_proc_entry+0x19f/0x1b0()
remove_proc_entry: removing
From: Daniel Baluta
This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.
[1]
Addy,
On Fri, Sep 5, 2014 at 3:17 AM, addy ke wrote:
> The following modifications is reasonable?
>
> static void rk3x_i2c_set_scl_rate(struct rk3x_i2c *i2c, unsigned long
> scl_rate)
> {
> unsigned long i2c_rate = clk_get_rate(i2c->clk);
> unsigned int div;
>
> /* set
On Sep 5, 2014, at 9:26 AM, Andreas Färber wrote:
> Hi,
>
> Am 03.09.2014 18:50, schrieb Georgi Djakov:
>> Add basic support for the IFC6540 single-board computer boards, that are
>> based on the APQ8084 SoC. This patch adds the initial device tree and the
>> neccessary nodes required for
From: Laurentiu Palcu
This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master
This patch series adds support for Diolan USB-I2C/GPIO Master Adapter DLN-2.
Details about device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Changes since v2:
* MFD driver: fix a few obsolete comments for the DLN2 I/O API
* GPIO driver: retry the chip remove call if
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
Because
On 5 Sep 2014, Oliver Neukum verbalised:
> On Fri, 2014-09-05 at 00:40 +0100, Nix wrote:
>> I'm working around this confusing morass by rebooting into each test
>> kernel, unplugging and replugging the entropy key if it was fubared,
>> then rebooting into the same kernel again and seeing if it
Hi Adrian and Arnaldo,
2014-09-05 (금), 11:11 -0300, Arnaldo Carvalho de Melo:
> Em Fri, Sep 05, 2014 at 10:22:40AM +0300, Adrian Hunter escreveu:
> > On 09/05/2014 07:59 AM, Namhyung Kim wrote:
> > > +++ b/tools/perf/util/machine.c
> > > @@ -1060,10 +1060,14 @@ static int
> > >
On Thu, Sep 04, 2014 at 12:07:40PM +0100, Mark Rutland wrote:
> Thanks for taking a look. If you have any ideas I'm happy to try another
> approach.
How horrible is the below patch (performance wise). It does pretty much
the same thing except that percpu_rw_semaphore is a lot saner, its
read side
On Thu, 4 Sep 2014, Paolo Bonzini wrote:
> Il 04/09/2014 22:58, Thomas Gleixner ha scritto:
> > This is simply wrong.
>
> It is.
>
> > Now I have no idea why you think it needs to add xtime_sec. If the
> > result is wrong, then we need to figure out which one of the supplied
> > values is wrong
Dave,
Please pull this batch of fixes intended for the 3.17 stream...
For the mac80211 bits, Johannes says:
"Here are a few fixes for mac80211. One has been discussed for a while
and adds a terminating NUL-byte to the alpha2 sent to userspace, which
shouldn't be necessary but since many places
On 09/05/2014 07:00 AM, Toshi Kani wrote:
>
> That's a fine idea, but as Ingo also suggested, I am going to disable
> this feature on all Pentium 4 models. That should give us a safety
> margin. Using slot 4 has a benefit that it keeps the PAT setup
> consistent with Xen.
>
Slot 4 is
Fix a NULL pointer dereference after unbinding the driver, if channel
resources were not yet allocated (no call to
pl330_alloc_chan_resources()):
$ echo 1285.mdma > /sys/bus/amba/drivers/dma-pl330/unbind
[ 13.606533] DMA pl330_control: removing pch: eeab6800, chan: eeab6814,
thread:
This patch adds both normal PM suspend/resume support and runtime PM
support to pl330 DMA engine driver.
The runtime power management for pl330 DMA driver allows gating of AMBA
clock (PDMA) in FSYS clock domain, when the device is not processing any
requests. This is necessary to enter W-AFTR low
On 09/04/2014 02:25 PM, Andrew Morton wrote:
>>
>> CC'ing Hannes, he sent a much simpler gcc5 patch a few days ago.
>> https://lkml.org/lkml/2014/8/26/710
>
> That approach won't last for long - as soon as we add some
> gcc5-specific thing, we'll need a new file.
>
> Let history be a guide:
>
>
Do not dereference the 'struct pl330_thread *thrd' before the check for
non-NULL value.
This fixes following warning:
drivers/dma/pl330.c:1376 pl330_submit_req() warn: variable dereferenced before
check 'thrd' (see line 1367)
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma/pl330.c | 3 ++-
If dma_async_device_register() returns error and probe should clean up
and return error, a NULL pointer exception happens because of
dereference of not allocated channel thread:
Dmesg log (from early printk):
dma-pl330 1268.pdma: unable to register DMAC
DMA pl330_control: removing pch:
On 09/05/2014 09:45 AM, Brian Norris wrote:
> On Fri, Sep 05, 2014 at 08:29:09AM +0200, Francis Moreau wrote:
>> On 09/04/2014 11:21 PM, Brian Norris wrote:
> [...]
>>> Signed-off-by: Rafael J. Wysocki
>>> Cc: # 3.10+: 27ddcc6596e5: PM / sleep: Add state
>>> field to pm_states[] entries
>>> Cc:
On Fri, Sep 05, 2014 at 11:25:37AM +0200, Michal Hocko wrote:
> @@ -900,10 +900,10 @@ void lru_add_drain_all(void)
> * grabbed the page via the LRU. If it did, give up: shrink_inactive_list()
> * will free it.
> */
> -void release_pages(struct page **pages, int nr, bool cold)
> +static void
The atmel,clk-divisors property is taking 4 divisors, if less are
provided, the clock registration will fail.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/at91rm9200.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
Shutdown properly the timer counter block by masking interruptions. Otherwise,
a segmentation may happen when kexec-ing a new kernel (see backtrace below).
An interruption may happen before the handler is set, leading to a kernel
segmentation fault.
Furthermore, we make sure the interruptions are
On 09/05/2014 12:08 AM, Hannes Frederic Sowa wrote:
> On Do, 2014-09-04 at 23:37 -0400, Sasha Levin wrote:
>> > On 09/04/2014 07:47 PM, Joe Perches wrote:
>>> > > On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote:
> > >> > Most statements are already depending on GCC_VERSION, maybe
On 09/05/2014 04:17 PM, Jens Axboe wrote:
>
> We need to do something about this. From this latest pull, looks like
> all should go to stable:
>
> 5b1016e62f74c53e0330403025954c8d95384c03
> 9aa61a992acceeec0d1de2cd99938421498659d5
> dbd810ab678d262d3772d29b65844d7b20dc47bc
>
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm+acpi-3.17-rc4
to receive ACPI and power management fixes for v3.17-rc4 with
top-most commit 9aa4e2f6ac2e5d0729f5982fd0b070123808381e
Merge branches 'pm-sleep', 'powercap', 'pm-domains' and
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:
[12191.987737] BUG: unable to handle kernel paging request at 88035615eca8
[12191.988865] IP: page_get_anon_vma (./arch/x86/include/asm/atomic.h:27
Hi Rob,
On 02/09/14 18:38, Rob Herring wrote:
> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann wrote:
>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>
> This alone is not okay. There is no such implementation of hardware.
But the SBSA explicitly allows this. I don't
The clock is not unprepared in case of the request IRQ fails.
Also update to request_irq.
Signed-off-by: Gaël PORTAY
Acked-by: Daniel Lezcano
Acked-by: Boris Brezillon
---
drivers/clocksource/tcb_clksrc.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
drivers/misc/atmel_tclib.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
index c8d8e38..b514a2d 100644
--- a/drivers/misc/atmel_tclib.c
+++
Move resource retrieval from atmel_tc_alloc to tc_probe to avoid lately
reporting resource related issues when a TC block user request a TC block.
Moreover, resources retrieval are usually done in the probe function,
thus moving them add some consistency with other drivers.
Initialization is
On 09/05/2014 08:28 AM, Vasiliy Tolstov wrote:
> 2014-09-05 18:17 GMT+04:00 Jens Axboe :
>>
>> We need to do something about this. From this latest pull, looks like
>> all should go to stable:
>>
>> 5b1016e62f74c53e0330403025954c8d95384c03
>> 9aa61a992acceeec0d1de2cd99938421498659d5
>>
Hi,
Linus Walleij wrote:
> commit 03e9f0cac5da6af85758276cb4624caf5911f2b9
> "pinctrl: clean up after enable refactoring"
> renamed the vtable callback .enable to .set_mux. The
> renaming was done manually, and one of the alterations
> contained a freudian slip. I confess, I am human.
>
>
2014-09-05 18:17 GMT+04:00 Jens Axboe :
>
> We need to do something about this. From this latest pull, looks like
> all should go to stable:
>
> 5b1016e62f74c53e0330403025954c8d95384c03
> 9aa61a992acceeec0d1de2cd99938421498659d5
> dbd810ab678d262d3772d29b65844d7b20dc47bc
>
On 02/09/14 20:34, Arnd Bergmann wrote:
> On Tuesday 02 September 2014 12:38:23 Rob Herring wrote:
>> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann wrote:
>>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>>
>> This alone is not okay. There is no such implementation of
Hi,
Am 03.09.2014 18:50, schrieb Georgi Djakov:
> Add basic support for the IFC6540 single-board computer boards, that are
> based on the APQ8084 SoC. This patch adds the initial device tree and the
> neccessary nodes required for enabling the serial port and eMMC.
>
> Signed-off-by: Georgi
Hi Arnd,
[...]
> A common pattern these days is to do dependencies like
>
> arch/*/Kconfig:
> config ARCH_FOO
> bool "Enable support for Foo platform"
> help
> ...
>
>
> drivers/*/Kconfig
> config SUBSYS_FOO
> bool "SUBSYS driver for Foo"
> depends
Hi every one,
This set of patches fix a segmentation fault happening when kexec-ing
kernel on an at91 platform (see backtrace below).
While the previous kernel shuts down, the tcb_clksrc driver leaves its
interruptions unmasked. When the new kernel initiliazes any tclib making use of
a TC block,
401 - 500 of 1674 matches
Mail list logo
