On Monday 19 January 2015 14:30:22 Rob Herring wrote:
> On Mon, Jan 19, 2015 at 1:16 PM, David Daney wrote:
> > On 01/19/2015 07:43 AM, Mark Rutland wrote:
> >>
> >> On Mon, Jan 19, 2015 at 03:23:58PM +, Aleksey Makarov wrote:
> >>>
> >>> The OCTEON SATA controller is currently found on
Currently, a lot of filesystem mounting functions feature in
file_system_type only to be called from vfs mount_fs and call mount_bdev.
This patch adds fill_super function to that structure and lets vfs
call mount_bdev when no mount function is declared.
Signed-off-by: Fabian Frederick
---
On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > There's also an issue in (most) X drivers which exaberates this
> > > issues: When changing the
Hi,
On Sun, Jan 04, 2015 at 06:55:18PM +0800, Hanjun Guo wrote:
> From: Graeme Gregory
>
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
>
> Reviewed-by: Suravee Suthikulpanit
> Signed-off-by: Graeme Gregory
> Signed-off-by: Al Stone
> Signed-off-by: Hanjun Guo
> ---
Peter Hurley wrote:
Ok.
I might see if I can get telnet + a revised kernel interface to work together;
I'll
let you know if this works out.
The patch here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585527#20 still
applies cleanly to current Ubuntu netkit-telnet source and works.
On Mon, Jan 19, 2015 at 08:07:34PM +0100, SF Markus Elfring wrote:
> >> I published scripts for static source code analysis in March 2004.
^^ That would be March 2014, not March 2004.
> > I didn't ask "when?"; where?
>
> https://lkml.org/lkml/2014/3/5/356
>
On Mon, Jan 19, 2015 at 1:16 PM, David Daney wrote:
> On 01/19/2015 07:43 AM, Mark Rutland wrote:
>>
>> On Mon, Jan 19, 2015 at 03:23:58PM +, Aleksey Makarov wrote:
>>>
>>> The OCTEON SATA controller is currently found on cn71XX devices.
[...]
>>> +
>>> + /* Set a good dma_mask */
>>>
On Mon, Jan 19, 2015 at 12:00:34PM -0800, shirish gajera wrote:
> I am confuse whether to wait till the patch got accepted or submit new
> patch set.
Just wait for Greg to get to the patch. We pretty much always apply
long line fixes so just assume it's going to merged.
>
> Also, how to
On Monday 19 January 2015 13:37:33 Gabriel Fernandez wrote:
> On 17 December 2014 at 23:14, Arnd Bergmann wrote:
> > On Wednesday 17 December 2014 11:34:44 Gabriel FERNANDEZ wrote:
> > > +/*
> > > + * On ARM platforms, we actually get a bus error returned when the PCIe
> > IP
> > > + * returns a
On Tue, Jan 20, 2015 at 02:38:06AM +0800, Greg Kroah-Hartman wrote:
> Yes, I do agree, there are lots of existing ipc solutions today that
> kdbus is not designed for, nor would it be good to use it for. The
> majority of them being IPC that crosses the network layer, as there are
> lots of good
Hi Romain
Am Montag, 19. Januar 2015, 18:08:05 schrieb Romain Perier:
> This series fixes few issues in dwmac-rk:
>
> 1. Voltage settings was hardcoded into the driver for the phy regulator.
>The driver now uses the default voltage settings found in the devicetree,
> which are applied
Am Montag, 19. Januar 2015, 18:08:08 schrieb Romain Perier:
> Currently, dwmac-rk uses a custom propety "phy_regulator" to get the name of
> the right regulator to use to power on or power off the phy. This commit
> converts the driver to use phy-supply devicetree property and the
> corresponding
From: Murali Karicheri
Date: Thu, 15 Jan 2015 19:10:03 -0500
> The Network Coprocessor (NetCP) is a hardware accelerator that processes
> Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
> switch sub-module to send and receive packets. NetCP also includes a packet
>
In order to ensure that filenames are not released before the audit
subsystem is done with the strings there are a number of hacks built
into the fs and audit subsystems around getname() and putname(). To
say these hacks are "ugly" would be kind.
This patch removes the filename hackery in favor
There are several areas in the kernel that create temporary filename
objects using the following pattern:
int func(const char *name)
{
struct filename *file = { .name = name };
...
return 0;
}
... which for the most part
In preparation for expanded use in the kernel, make getname_kernel()
more useful by allowing it to handle any legal filename length.
CC: v...@zeniv.linux.org.uk
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Paul Moore
Reviewed-by: Richard Guy Briggs
---
fs/namei.c | 34
Enable recording of filenames in getname_kernel() and remove the
kludgy workaround in __audit_inode() now that we have proper filename
logging for kernel users.
CC: v...@zeniv.linux.org.uk
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Paul Moore
Reviewed-by: Richard Guy Briggs
---
In all likelihood there were some subtle, and perhaps not so subtle,
bugs with filename matching in audit_inode() and audit_inode_child()
for some time, however, recent changes to the audit filename code have
definitely broken the filename matching code. The breakage could
result in duplicate
This is the same patchset that was sent earlier with the RFC prefix,
the only differences are the inclusion of a reviewer and the fact that
I've stripped the RFC prefix. I'm including this in the audit-next
branch and plan on pushing this to Linus in the next merge window.
For those of you who
On Mon, Jan 19, 2015 at 08:48:42PM +0100, Jiri Kosina wrote:
> On Mon, 19 Jan 2015, Josh Poimboeuf wrote:
>
> > > If this is implemented really in a fully stackable manner (i.e. you
> > > basically would be able to disable only the function that is currently
> > > "active", i.e. on top of the
On Mon, Jan 19, 2015 at 07:45:31PM +, John Youn wrote:
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Monday, January 19, 2015 6:47 AM
> >
> > looking at Synopsys Solvnet for this IP, it shows that current version
> > is 2.90a. There's no 3.00a.
On 01/19/2015 07:55 PM, Wolfram Sang wrote:
[...]
Let's get rid of this code before really nobody knows/understands
anymore what this was for and if it has a subtle use.
Getting rid of this is the right thing, cause it's just not how it should be
done, but unfortunately it is not as simple
On Mon, 19 Jan 2015, Josh Poimboeuf wrote:
> > If this is implemented really in a fully stackable manner (i.e. you
> > basically would be able to disable only the function that is currently
> > "active", i.e. on top of the stack), woudln't that provide more
> > predictable semantics?
>
> Yes,
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Monday, January 19, 2015 6:47 AM
>
> looking at Synopsys Solvnet for this IP, it shows that current version
> is 2.90a. There's no 3.00a. Paul, John, is there a 3.00a version of the
> DWC USB3 IP ?
Yes there
On 01/19/2015 01:57 AM, Srinivas Kandagatla wrote:
> Some of the clks can be registered & unregistered before the clk related
> debugfs
> entries are initialized at late_initcall. In the unregister path checking for
> only
> dentry before clk_debug_init() would lead dangling pointers in the
To see why atomic_t is pure obfuscation:
typedef struct {
int counter;
} atomic_t;
So, counter is a plain int.
On Mon, Jan 19, 2015 at 11:23:47AM -0800, Ray Jui wrote:
> +static irqreturn_t bcm_iproc_i2c_isr(int irq, void *data)
> +{
> + struct bcm_iproc_i2c_dev *iproc_i2c = data;
>
Peter Hurley wrote:
On 01/19/2015 11:36 AM, Howard Chu wrote:
Peter Hurley wrote:
Thanks, Howard.
[ adding Ted too ]
On 01/19/2015 07:46 AM, Howard Chu wrote:
Peter Hurley wrote:
On 01/18/2015 05:45 PM, Howard Chu wrote:
Peter Hurley wrote:
Commit 26df6d13406d1 ("tty: Add EXTPROC support
* Tony Lindgren [150119 10:52]:
> * Roger Quadros [150119 09:55]:
> > Both are needed for USB cable type detection on dra7-evm.
> >
> > Signed-off-by: Roger Quadros
> > ---
> > arch/arm/configs/omap2plus_defconfig | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git
On Thu, Jan 15, 2015 at 06:09:42PM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> A little defconfig update. If you want me to collect more patches before
> sending you a more substantial one, let me know.
>
> Thanks, bye,
>
> The following changes since commit
which blocks describe
UART0 and UART1.
Signed-off-by: Paul Bolle
---
Created on top of next-20150119. Untested! Note that I know nothing
about this board or about DT source files, so all changes are nothing
more than guesses.
arch/arm/boot/dts/armada-xp-axpwifiap.dts | 6 --
1 file changed, 4
On 01/19/2015 11:36 AM, Howard Chu wrote:
> Peter Hurley wrote:
[...]
>> A description of how the pty master uses EXTPROC to implement line mode would
>> be very helpful, especially to people working in the tty code (eg., me,
>> although
>> I don't need it now).
>
> The original patch
On Thu, Jan 15, 2015 at 06:02:30PM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> This is a pull-request about AT91 drivers for 3.20. We took the USB gadget
> part
> with us as it depends on the Matrix syscon part. There is no dependency
> anyway.
>
> Thanks, best regards,
>
> The
On Mon, Jan 19, 2015 at 07:12:10PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 19, 2015 at 07:55:56PM +0100, Wolfram Sang wrote:
> > Back in the days, sysfs seemed to have refcounting issues and subsystems
> > needed a completion to be safe. This is not the case anymore, so I2C can
> >
Am 19.01.2015 um 15:33 schrieb kbuild test robot:
> tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
> head: cdef511985374dd042a40bb32c1c346c2662c9dc
> commit: cdef511985374dd042a40bb32c1c346c2662c9dc [1/1] KVM: fix sparse
> warning in include/trace/events/kvm.h
> reproduce:
> #
Lee Jones writes:
> On Fri, 16 Jan 2015, Robert Jarzmik wrote:
>
>> Add a binding for lubbock motherboard IO board.
>>
>> Signed-off-by: Robert Jarzmik
>> ---
>> .../devicetree/bindings/mfd/lubbock-io.txt | 26
>> ++
>> 1 file changed, 26 insertions(+)
>> create
On Sat, Jan 17, 2015 at 04:30:33PM -0800, Ray Jui wrote:
>
>
> On 1/17/2015 2:40 PM, Russell King - ARM Linux wrote:
> > On Sat, Jan 17, 2015 at 01:26:41PM -0800, Ray Jui wrote:
> >>time_left = wait_for_completion_timeout(_i2c->done, time_left);
> >>
> >>/* disable all interrupts */
> >>
Adding some more people to CC.
On Tue, Jan 06, 2015 at 03:51:11PM +0100, Joerg Roedel wrote:
> v1->v2:
>
> * Updated comments based on feedback from Konrad
> * Added Acked-bys
> * Rebased to v3.19-rc3
>
> Hi,
>
> here is a patch-set to fix failed kdump kernel boots when
> the systems was
On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote:
> On Fri, 16 Jan 2015, Mark Brown wrote:
> >What I'm saying is that I want to understand this change from a point of
> >view that isn't tied to I2C - at the regmap level what is this doing,
> From the regmap point of view, it
Document the I2C device tree binding for Broadcom iProc family of
SoCs
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37
1 file changed, 37 insertions(+)
create mode 100644
This patchset contains the initial I2C support for Broadcom iProc family of
SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has a
size of 64 bytes. The iProc I2C controller supports two bus speeds including
standard mode (100 kHz) and fast mode (400 kHz)
Changes from
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi |
On Thu, Jan 15, 2015 at 05:52:18PM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> Some Device Tree updates for 3.20. There is no dependency for this material as
> the drivers are already updated or not needed (syscon).
>
> Thanks, best regards,
>
> The following changes since commit
On Thu, Jan 15, 2015 at 05:42:50PM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> Some AT91 cleanup for 3.20, but definitively, more to come soon.
>
> Thanks, best regards,
>
> The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115:
>
> linux 3.19-rc4 (2015-01-11
On 01/17, Rasmus Villemoes wrote:
>
> Using kasprintf to get the function name makes us look up the name
> twice, along with all the vsnprintf overhead of parsing the format
> string etc. It also means there is an allocation failure case to deal
> with. Since symbol_string in vsprintf.c would
On 01/19/2015 09:20 AM, Tomeu Vizoso wrote:
> As clk_unprepare_unused_subtree and clk_disable_unused_subtree are
> always called with a valid struct clk.
>
> Signed-off-by: Tomeu Vizoso
Reviewed-by: Stephen Boyd
thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a
From: Nicolas Dichtel
Date: Thu, 15 Jan 2015 15:11:14 +0100
> The goal of this serie is to be able to multicast netlink messages with an
> attribute that identify a peer netns.
> This is needed by the userland to interpret some information contained in
> netlink messages (like IFLA_LINK value,
On 1/18/2015 4:13 AM, Arend van Spriel wrote:
> On 01/18/15 12:56, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Sun, Jan 18, 2015 at 12:46:51PM +0100, Arend van Spriel wrote:
>>> On 01/18/15 12:17, Uwe Kleine-König wrote:
Hello Wolfram,
On Sun, Jan 18, 2015 at 12:06:58PM +0100,
On 01/19/2015 07:43 AM, Mark Rutland wrote:
On Mon, Jan 19, 2015 at 03:23:58PM +, Aleksey Makarov wrote:
The OCTEON SATA controller is currently found on cn71XX devices.
Signed-off-by: David Daney
Signed-off-by: Vinita Gupta
[aleksey.maka...@auriga.com: preparing for submission,
conflict
Hi Jason,
On Sun, Nov 16, 2014 at 10:34 AM, Geert Uytterhoeven
wrote:
> Hi Jason,
>
> On Fri, Nov 14, 2014 at 6:05 PM, Jason Cooper wrote:
>> On Fri, Nov 14, 2014 at 05:38:44PM +0100, Ralf Baechle wrote:
>>> On Mon, Nov 10, 2014 at 09:13:49AM +0100, Geert Uytterhoeven wrote:
>>>
>>> > On Fri,
On Mon, Jan 19, 2015 at 07:55:56PM +0100, Wolfram Sang wrote:
> Back in the days, sysfs seemed to have refcounting issues and subsystems
> needed a completion to be safe. This is not the case anymore, so I2C can
> get rid of this code. There is noone else besides I2C doing something
> like this
On 01/19/2015 11:36 AM, Howard Chu wrote:
> Peter Hurley wrote:
>> Thanks, Howard.
>>
>> [ adding Ted too ]
>>
>> On 01/19/2015 07:46 AM, Howard Chu wrote:
>>> Peter Hurley wrote:
On 01/18/2015 05:45 PM, Howard Chu wrote:
> Peter Hurley wrote:
>> Commit 26df6d13406d1 ("tty: Add
Lee Jones writes:
> On Fri, 16 Jan 2015, Robert Jarzmik wrote:
>
>> As a fix, move the gpio0 chained handler setup to a place where we have
>> the guarantee that pxa_gpio_probe() was called before, so that lubbock
>> handler becomes the true IRQ chained handler of GPIO0, demuxing the
>> lubbock
>> I published scripts for static source code analysis in March 2004.
>
> I didn't ask "when?"; where?
https://lkml.org/lkml/2014/3/5/356
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
https://systeme.lip6.fr/pipermail/cocci/2014-March/000676.html
Do you get further ideas
Hi Stephen,
> Stephen Warren hat am 19. Januar 2015 um 18:13
> geschrieben:
>
>
> On 01/19/2015 04:00 AM, Stefan Wahren wrote:
> > This patch adds root compatible properties for the following boards:
> > - Raspberry Pi Model A
> > - Raspberry Pi Model A+
> > - Raspberry Pi Model B
> > -
On 01/19/2015 06:28 AM, Mark Rutland wrote:
Hi,
On Mon, Jan 19, 2015 at 01:46:36PM +, Aleksey Makarov wrote:
The OCTEON MMC controller is currently found on cn61XX and cnf71XX
devices. Device parameters are configured from device tree data.
Currenly supported are eMMC, MMC and SD
Hi Wolfram,
> On Jan 19, 2015, at 20:55 , Wolfram Sang wrote:
>
> Back in the days, sysfs seemed to have refcounting issues and subsystems
> needed a completion to be safe. This is not the case anymore, so I2C can
> get rid of this code. There is noone else besides I2C doing something
> like
Back in the days, sysfs seemed to have refcounting issues and subsystems
needed a completion to be safe. This is not the case anymore, so I2C can
get rid of this code. There is noone else besides I2C doing something
like this currently (checked with the attached coccinelle script which
checks if a
I went digging through some of Markus's old patch history, and noticed
this...
On Mon, Nov 03, 2014 at 12:50:59PM +0300, Dan Carpenter wrote:
> This one is buggy.
>
> I'm sorry, but please stop sending these.
I'm tending to concur.
> For kfree(), at least we all know that kfree() accepts NULL
Afaics there is no reason why kernel threads should have FPU context
even if use_eager_fpu() == T. Now that interrupted_kernel_fpu_idle()
does not check __thread_has_fpu() we can remove the init_fpu() code
from eager_fpu_init() and change flush_thread() called by do_execve()
to initialize FPU.
The __thread_has_fpu() check in interrupted_kernel_fpu_idle() was needed
to prevent the nested kernel_fpu_begin(). Now that we have in_kernel_fpu
and !__thread_has_fpu() case in __kernel_fpu_begin() does not depend on
use_eager_fpu() (except clts) we can remove it.
__thread_has_fpu() can be false
On 01/15, Oleg Nesterov wrote:
>
> Let me send initial kernel_fpu_begin/end cleanups, I believe they make
> sense anyway and won't conflict with your changes.
>
> This is actually resend, I sent more patches some time ago but they were
> ignored.
>
> Note that (I hope) we can do more changes on
__kernel_fpu_begin() does nothing if !__thread_has_fpu() && use_eager_fpu(),
perhaps it assumes that this case is simply impossible. This is certainly
not possible if in_interrupt() == T; interrupted_user_mode() should have
FPU, and interrupted_kernel_fpu_idle() should fail if !__thread_has_fpu().
From: Markus Elfring
Date: Mon, 19 Jan 2015 17:56:11 +0100
The iounmap() function could be called in three cases by the w100fb_probe()
function during error handling even if the passed data structure element
contained still a null pointer.
* This implementation detail could be improved by
* Roger Quadros [150119 09:55]:
> Both are needed for USB cable type detection on dra7-evm.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/configs/omap2plus_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig
>
On Mon, Jan 19, 2015 at 3:53 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> If the image size would ever read as 0, pci_get_rom_size could keep
> processing the same image over and over again.
>
> Reported-by: Federico
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michel Dänzer
From: Markus Elfring
Date: Mon, 19 Jan 2015 17:01:25 +0100
The iounmap() function could be called in three cases by the valkyriefb_init()
function during error handling even if the passed data structure element
contained still a null pointer.
This implementation detail could be improved by
From: Markus Elfring
Date: Mon, 19 Jan 2015 15:30:45 +0100
The iounmap() function could be called in one case by the tgafb_register()
function during error handling even if the passed variable "mem_base"
contained still a null pointer.
This implementation detail could be improved by adjustments
From: Markus Elfring
Date: Mon, 19 Jan 2015 14:50:44 +0100
The iounmap() function could be called in two cases by the pvr2fb_common_init()
function during error handling even if the passed data structure element
contained still a null pointer.
This implementation detail could be improved by
On 01/19/2015 01:55 AM, Tomeu Vizoso wrote:
> On 17 January 2015 at 02:02, Stephen Boyd wrote:
>> On 01/12, Tomeu Vizoso wrote:
>>
>>> +}
>>> EXPORT_SYMBOL_GPL(__clk_get_rate);
>>>
>>> @@ -630,7 +656,12 @@ out:
>>> return !!ret;
>>> }
>>>
>>> -bool __clk_is_enabled(struct clk *clk)
>>>
On Mon, Jan 19, 2015 at 07:06:42PM +0100, Johannes Stezenbach wrote:
> Hi Greg and Daniel,
[Fixing Daniel's email, which I messed up originally...]
> On Fri, Jan 16, 2015 at 11:16:04AM -0800, Greg Kroah-Hartman wrote:
> > kdbus is a kernel-level IPC implementation that aims for resemblance to
>
From: Markus Elfring
Date: Mon, 19 Jan 2015 14:18:47 +0100
The functions "iounmap" and "kfree" could be called in a few cases by the
trident_pci_probe() function during error handling even if the passed data
structure element contained still a null pointer.
This implementation detail could be
* Jason Cooper [150106 19:03]:
> On Tue, Jan 06, 2015 at 02:38:08PM -0600, Felipe Balbi wrote:
> > commit 55601c9f2467 (arm: omap: intc: switch over
> > to linear irq domain) introduced a regression with
> > SDMA legacy driver because that driver strictly depends
> > on INTC's IRQs starting at
From: Markus Elfring
Date: Mon, 19 Jan 2015 13:18:50 +0100
The return value from a call of the ioremap() function was not checked
by the implementation of the cirrusfb_pci_register() function.
Let us complete the corresponding error detection and exception handling
at this source code place.
(resend, fix Daniel's email address)
Hi Greg and Daniel,
I don't have a clue so I need to ask some stupid questions...
On Fri, Jan 16, 2015 at 11:16:04AM -0800, Greg Kroah-Hartman wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the
On Mon, Jan 19, 2015 at 09:20:47PM +0300, Dan Carpenter wrote:
> The sparc iounmap() implementation in arch/sparc/kernel/ioport.c looks
> it prints an error message if you pass a NULL pointer.
Seems that way. Thanks.
Nak to the patch then.
Brian
--
To unsubscribe from this list: send the line
Hi Greg and Daniel,
I don't have a clue so I need to ask some stupid questions...
On Fri, Jan 16, 2015 at 11:16:04AM -0800, Greg Kroah-Hartman wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
On Mon, Jan 19, 2015 at 07:19:34PM +0100, SF Markus Elfring wrote:
> > Anyway, I'm essentially saying that I'd like to be 100% sure we have a
> > guarantee before dropping all these.
>
> You can not be absolutely sure. There are various implementation details
> which will eventually need further
From: Markus Elfring
Date: Mon, 19 Jan 2015 11:30:33 +0100
The iounmap() function could be called in two cases by the vesafb_probe()
function during error handling even if the passed data structure element
contained still a null pointer.
This implementation detail could be improved by
the if (CISLAND_MINIMUM_ENGINE_CLOCK !=
> CISLAND_MINIMUM_ENGINE_CLOCK) is never
> satisfied - the entire else branch is never going to be executed and could be
> removed - provided this is not simply a bug and needs to be fixed...
>
> Patch is against 3.19.0-rc5 -next-20150119
>
> Patch was
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git
tags/qcom-soc-for-3.20
for you to fetch changes up to
19.01.2015 21:00, Dmitry Osipenko пишет:
19.01.2015 20:45, Stephen Warren пишет:
On 01/19/2015 10:41 AM, Dmitry Osipenko wrote:
19.01.2015 20:26, Stephen Warren пишет:
Hopefully this works out. I suppose it's unlikely anyone will be
running code on
the AVP upstrem, so any potential conflict
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git
tags/qcom-dt-for-3.20
for you to fetch changes up to
From: Markus Elfring
Date: Sun, 18 Jan 2015 23:30:41 +0100
The iounmap() function could be called in two cases by the tdfxfb_probe()
function during error handling even if the passed data structure element
contained still a null pointer.
This implementation detail could be improved by
On Mon, Jan 19, 2015 at 12:18:58PM -0600, Aravind Gopalakrishnan wrote:
> The NodeId field in cpuid_ecx(0x801e) is a 8 bit field.
> Although current extractor works fine, it will break if/when
> the most significant 5 bits ever get used.
>
> So, lets honor the field as architected in the BKDG
The sparc iounmap() implementation in arch/sparc/kernel/ioport.c looks
it prints an error message if you pass a NULL pointer.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu, Jan 15, 2015 at 2:16 AM, Greg Kroah-Hartman
wrote:
> On Wed, Jan 14, 2015 at 11:40:54PM +0530, ashishsangw...@gmail.com wrote:
>> From: Ashish Sangwan
>>
>> We have hit a race condition while parallely accessing device's uevent
>> and rmmoding device's driver.
>
> How are you doing that?
> Anyway, I'm essentially saying that I'd like to be 100% sure we have a
> guarantee before dropping all these.
You can not be absolutely sure. There are various implementation details
which will eventually need further considerations.
I hope that a reasonable confidence can be achieved here.
Resending with Matt's current email address.
-- Steve
On Mon, Jan 19, 2015 at 12:51:25PM -0500, Steven Rostedt wrote:
>
> Matt,
>
> You initially added this code. Are you OK with this change?
>
> -- Steve
>
> On Sun, Jan 18, 2015 at 12:36:15AM +0100, Michael Karcher wrote:
> > Signed-Off-By:
This series fixes few issues in dwmac-rk:
1. Voltage settings was hardcoded into the driver for the phy regulator.
The driver now uses the default voltage settings found in the devicetree,
which are
applied throught the regulator framework.
2. The regulator name used to power on or power
This replaces the property phy_regulator by the standard devicetree property
phy-supply and references the device_node vcc_phy from it.
Signed-off-by: Romain Perier
---
arch/arm/boot/dts/rk3288-evb-rk808.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Signed-off-by: Romain Perier
---
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 489643c..1c08eb0 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++
On Wed, Apr 16, 2014 at 12:13 PM, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
>
> Upon closer examination pxa2xx-uart turned out to
Currently, dwmac-rk uses a custom propety "phy_regulator" to get the name of the
right regulator to use to power on or power off the phy. This commit converts
the
driver to use phy-supply devicetree property and the corresponding API, it
cleans
the code a bit and make it simpler to maintain.
On Sun, 18 Jan 2015, Vince Weaver wrote:
> On Fri, 16 Jan 2015, Vince Weaver wrote:
>
> I've continued fuzzing all weekend, with PeterZ's patch
> applied to 3.19-rc4. It has managed to stay up without crashing,
> impressive.
That was on my core2 system.
I tried on my
As these settings can be directly expressed from devicetree for both fixed
regulators and pmic-integrated regulators, it is more standard to set them
from dts and let the regulator framework use the right voltage informations
when it is used in the driver.
Signed-off-by: Romain Perier
---
The NodeId field in cpuid_ecx(0x801e) is a 8 bit field.
Although current extractor works fine, it will break if/when
the most significant 5 bits ever get used.
So, lets honor the field as architected in the BKDG
Reference: BKDG for AMD Fam15h Models 00h-0fh,
CPUID Fn8000_001E_ECX Node
On Mon, Jan 19, 2015 at 08:58:58PM +0300, Dan Carpenter wrote:
> "error" is a crap label name because it doesn't tell you what the code
> does. A better name is "err_free_chan" or something which talks about
> freeing the channel.
If you choose your label names correctly, then most of the time
On Sun, 18 January 2015 Linus Torvalds wrote:
> Another week, another -rc.
>
> Fairly normal release, although I'd wish that by rc5 we'd have calmed
> down even further. But no, with some of the driver tree merges in
> particular, this is actually larger than rc4 was.
>
> That said, it's not
On Mon, Jan 19, 2015 at 05:52:33PM +, Catalin Marinas wrote:
> On Mon, Jan 19, 2015 at 04:59:47PM +, Jon Masters wrote:
> > On 01/19/2015 10:13 AM, Grant Likely wrote:
> > > On Mon, 19 Jan 2015 13:51:45 +
> > > , Catalin Marinas
> > > wrote:
> > >> On Mon, Jan 19, 2015 at 11:55:32AM
301 - 400 of 1606 matches
Mail list logo
