Hi,
Quick question: As I'm new at this (submitting patches), what is a reasonable
time to wait before ping-ing a patch ?
Oren.
On 06/29/2014 01:01 PM, Oren Twaig wrote:
> When a vSMP Foundation box is detected, the function apic_cluster_num() counts
> the number of APIC clusters found. If more t
Hi,
Quick question: As I'm new at this (submitting patches), what is a reasonable
time to wait before ping-ing a patch ?
Oren.
On 06/29/2014 01:01 PM, Oren Twaig wrote:
> When a vSMP Foundation box is detected, the function apic_cluster_num() counts
> the number of APIC clusters found. If more
No I didn't I finally learned how to cross compile the kernel it's not
hard just have to find the docs for it :).
Cheers Nick
On Sat, Jul 5, 2014 at 10:43 AM, Randy Dunlap wrote:
> On 07/04/2014 07:50 PM, Nicholas Krause wrote:
>> This patch addes a #ifdef __ASSEMBLY__ in order to check if this p
Both tests for powerpc I can't test as I don't known where the configs
for all yes and random are for powerpc.
Cheers Nick
On Sun, Jul 6, 2014 at 1:34 AM, Nick Krause wrote:
> Here are my test logs for arm. Most of the failures from these builds
> not having default configures or make one by on
Here are my test logs for arm. Most of the failures from these builds
not having default configures or make one by one errors. Below are
my typed results. In the next message I will be sending logs for powerpc.
Results
iop13xx_defconfig - Successes in my tests
mackerel_defconfig - Fails in my test
Sorry my mistake some of this are wrong I will resend.
Cheers Nick
On Sun, Jul 6, 2014 at 1:17 AM, Nick Krause wrote:
> Here are my test logs for arm. Most of the failures from these builds
> not having default configures or make one by one errors. Below are
> my typed results.
> Results
> iop13
Here are my test logs for arm. Most of the failures from these builds
not having default configures or make one by one errors. Below are
my typed results.
Results
iop13xx_defconfig - Successes in my tests
mackerel_defconfig - Fails in my tests
nuc910_defconfig - Fails in my tests
nuc950_defconfig
On Sat, Jul 5, 2014 at 1:26 PM, Thomas Gleixner wrote:
> On Mon, 30 Jun 2014, Austin Schuh wrote:
>> I think I might have an answer for my own question, but I would
>> appreciate someone else to double check. If list_empty erroneously
>> returns that there is work to do when there isn't work to d
Hey guys ,
I checking Sachin Karmat's tests and fixing compile issues with
patches if need be. In my next email I am going to give a up to date
log of still failing builds for arm.
Cheers Nick
On Sat, Jul 5, 2014 at 10:57 AM, Sachin Kamat wrote:
> On Sat, Jul 5, 2014 at 6:18 AM, J. Bruce Fields
This is a set of 13 fixes, a MAINTAINERS update and a sparse update.
The fixes are mostly correct value initialisations, avoiding NULL derefs
and some uninitialised pointer avoidance.
All the patches have been incubated in -next for a few days. The final
patch (use the scsi data buffer length to
Hello, I'm Norman Chan, Tak-Lam, S.B.S., J.P, Chief Executive, Hong Kong
Monetary Authority (HKMA). I have a monetary proposal worth $47.1M for you to
handle with me. Contact me for more details.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hi Maxime,
El 30/06/14 10:20, Maxime Ripard escribió:
The Allwinner A31 has a 16 channels DMA controller that it shares with the
newer A23. Although sharing some similarities with the DMA controller of the
older Allwinner SoCs, it's significantly different, I don't expect it to be
possible to sh
Hi Dave,
This is NOT fixing problems with a stalled boot due to VGA problems as
reported in thread: [PATCH 5/5] drm/i915: Kick out vga console
It can be fixed by reverting: a4de05268e674e8ed31df6348269e22d6c6a1803
or applying the patch from Chris Wilson which can be found as a reply to my
report.
Hi,
The kernel in question is running on a i7 with a pi connected via to the i6 via
the pl2303 to view the pi's console.
The kernel on the i7 is at level:
commit 77c4cf17ae867ba93233b3832bda3de7adaae326
Merge: 88b5a85 133d452
Author: Linus Torvalds
Date: Fri Jul 4 09:37:43 2014 -0700
There
Hi,
This patchset superseeds the patch sets submitted with [1] and [2]. It
rebases all non-applied patches to the current Herbert Xu's
cryptodev-2.6 tree.
[1] https://lkml.org/lkml/2014/6/28/497
[2] https://lkml.org/lkml/2014/7/1/332
Stephan Mueller (6):
DRBG: cleanup of preprocessor macros
The structure used to construct the module description line was marked
problematic by the sparse code analysis tool. The module line
description now does not contain any ifdefs to prevent error reports
from sparse.
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
crypto/drbg.c
The initial format strings caused warnings on several architectures. The
updated format strings now match the variable types.
Reported-by: kbuild test robot
Reported-by: Randy Dunlap
CC: Joe Perches
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 4 ++--
1 file changed, 2 insertions(+), 2
The CTR DRBG requires the update function to be called twice when
generating a random number. In both cases, update function must process
the additional information string by using the DF function. As the DF
produces the same result in both cases, we can save one invocation of
the DF function when
When the DRBG is initialized, the core is looked up using the DRBG name.
The name that can be used for the lookup is registered in
cra_driver_name. The cra_name value contains stdrng.
Thus, the lookup code must use crypto_tfm_alg_driver_name to obtain the
precise DRBG name and select the correct D
The current locking approach of the DRBG tries to keep the protected
code paths very minimal. It is therefore possible that two threads query
one DRBG instance at the same time. When thread A requests random
numbers, a shadow copy of the DRBG state is created upon which the
request for A is process
The patch corrects the security strength of the HMAC-SHA1 DRBG to 128
bits. This strength defines the size of the seed required for the DRBG.
Thus, the patch lowers the seeding requirement from 256 bits to 128 bits
for HMAC-SHA1.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 2 +-
1 file ch
On Wed, 25 Jun 2014, Kishon Vijay Abraham I wrote:
> Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
> Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
> for pcie1 phy and pcie2 phy.
>
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: Paul Walmsley
> Signed-off-b
Hi
On Fri, 4 Jul 2014, Roger Quadros wrote:
> On 07/03/2014 10:48 PM, Paul Walmsley wrote:
> > On Thu, 3 Jul 2014, Roger Quadros wrote:
> >
> >> This module is needed for the SATA and PCIe PHYs.
> >>
> >> Signed-off-by: Roger Quadros
> >> Reviewed-by: Rajendra Nayak
> >> Tested-by: Sekhar Nori
We check that the struct vm_area_struct pointer vma is NULL and then
dereference it a few lines below. The intent was to make sure vma is
not NULL but this is not necessary since the bug pre-dates GIT history
and seem to never have caused a problem. The tlb-4k and tlb-8k versions
of local_flush_tlb
Hello,
On Sat, Jul 05, 2014 at 09:10:44PM +0200, Jonas Gorski wrote:
> On Sat, Jul 5, 2014 at 8:26 PM, Emil Goode wrote:
> > We check that the struct vm_area_struct pointer vma is NULL and then
> > dereference it a few lines below. The intent must have been to make sure
> > that vma is not NULL a
While a queue is being destroyed, all the blkgs are destroyed and its
->root_blkg pointer is set to NULL. If someone else starts to drain
while the queue is in this state, the following oops happens.
NULL pointer dereference at 0028
IP: [] blk_throtl_drain+0x84/0x230
PGD e4a1067
Hi Linus,
i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA
connectors, along with some fixes for the tda998x from Russell fixing some
modesetting problems.
(still on holidays, but got a spare moment to find these).
Dave.
The following changes since commit e1a08b855f56
On Fri, Jul 4, 2014 at 8:17 AM, Andy Lutomirski wrote:
> On Wed, Jul 2, 2014 at 7:29 PM, Alexei Starovoitov wrote:
>>
>> non-root API:
>>
>> ufd = bpf_create_map(local_map_id,… )
>> bpf_map_update/delete/lookup_elem(ufd,…)
>> ufd = bpf_prog_load(insns)
>> close(ufd)
>>
>> root only API:
>>
>> glo
On Sat, Jul 05, 2014 at 03:26:29PM -0600, Bjorn Helgaas wrote:
> I saw that Joerg applied those iommu changes to his core branch, which I
> assume will be merged for v3.17. So I'll move this to a pci/iommu branch,
> to be merged during the v3.17 merge window.
Yes, these changes are queued for v3.
At Sat, 5 Jul 2014 12:10:58 -0700,
Greg Kroah-Hartman wrote:
>
> On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote:
> > At Sat, 05 Jul 2014 18:21:04 +0900,
> > Satoru Takeuchi wrote:
> > >
> > > Hi Greg,
> > >
> > > Add Takashi Iwai to this thread.
> > >
> > > At Sat, 05 Jul 2014 16:
[+cc Joerg]
On Sat, Jul 05, 2014 at 10:31:43AM -0600, Bjorn Helgaas wrote:
> On Mon, Jun 23, 2014 at 04:36:25PM -0600, Alex Williamson wrote:
> > This bridge sometimes shows up as a root complex device and sometimes
> > as a discrete PCIe-to-PCI bridge. Testing indicates that in the
> > latter ca
On Fri, 2014-07-04 at 16:11 +0100, Andy Whitcroft wrote:
> On Thu, Jul 03, 2014 at 05:46:56PM -0700, Joe Perches wrote:
> > Whenever files are added, moved, or deleted, the
> > MAINTAINERS file patterns can be out of sync or
> > outdated.
> >
> > To try to keep MAINTAINERS more up-to-date, add a
>
On Sat, Jul 05, 2014 at 11:06:28PM +0200, Jiri Kosina wrote:
> On Sat, 5 Jul 2014, Tejun Heo wrote:
>
> > It'd be awesome if people who are working on the features can talk to
> > each other and see whether things can be combined.
>
> Oh, I absolutely agree; trust me, we are trying to get as much
On Sat, 5 Jul 2014, Tejun Heo wrote:
> It'd be awesome if people who are working on the features can talk to
> each other and see whether things can be combined.
Oh, I absolutely agree; trust me, we are trying to get as much discussion
going on as possible :) I proposed it as a Kernel Summit top
Hello,
On Sat, Jul 05, 2014 at 10:49:18PM +0200, Jiri Kosina wrote:
> Quite frankly, I have to say that I don't personally see *that* big
> difference. In both cases we are making assumptions about semantics, and
> are trying to get "as close as possible" to the point in time where the
> set of
On Sat, Jul 05, 2014 at 12:03:08PM -0300, Ezequiel Garcia wrote:
> After following Gregory's stacktrace (also reproduced here):
>
> [] (iommu_bus_notifier) from []
> (notifier_call_chain+0x64/0x9c)
> [] (notifier_call_chain) from []
> (__blocking_notifier_call_chain+0x40/0x58)
> [] (__blocking_n
On Tue, Jun 24, 2014 at 11:38 PM, Vineet Gupta
wrote:
> On Wednesday 25 June 2014 02:31 AM, Rob Herring wrote:
>> On Tue, Jun 24, 2014 at 3:25 AM, Vineet Gupta
>> wrote:
>>> Signed-off-by: Vineet Gupta
>>> ---
>>> drivers/tty/serial/arc_uart.c | 22 ++
>>> 1 file changed, 6
From: Steven Stewart-Gallus
---
This is my first kernel patch but this is really trivial so I hope I'm doing
this right.
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index 074b886..92223f0 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -38,9 +
On Sat, 5 Jul 2014, Tejun Heo wrote:
> > What we need is to have a defined point in execution where we can draw a
> > line between "old" and "new" universes. For processess that are crossing
> > the userspace/kernelspace boundary, the obvious choice, that covers most
> > of the use-cases, has b
On Saturday 05 July 2014 14:25:52 Rob Herring wrote:
> On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau wrote:
> > The ranges property for a host bridge controller in DT describes
> > the mapping between the PCI bus address and the CPU physical address.
> > The resources framework however expects that
Because gcc issues a complaint about any pointer format with %#p,
remove the use of SPECIAL to prefix 0x to various pointer types.
There are no uses in the kernel tree of %#p.
This removes the capability added by commit 725fe002d315
("vsprintf: correctly handle width when '#' flag used in %#p for
On Wed, 21 May 2014, John Blackwood wrote:
> I'm not 100% sure that the patch below will fix your problem, but we
> saw something that sounds pretty familiar to your issue involving the
> nvidia driver and the preempt-rt patch. The nvidia driver uses the
> completion support to create their own dr
Hello,
On Sat, Jul 05, 2014 at 10:04:52PM +0200, Jiri Kosina wrote:
> What we need is to have a defined point in execution where we can draw a
> line between "old" and "new" universes. For processess that are crossing
> the userspace/kernelspace boundary, the obvious choice, that covers most
>
The following patches fix some warnings reported by checkpatch.pl
Pawel Lebioda (2):
staging: nvec: remove unnecessary 'else' after 'return' statement
staging: nvec: remove unneccessary 'out of memory' message
drivers/staging/nvec/nvec.c | 8 +++-
1 file changed, 3 insertions(+), 5 delet
Fix the following warning reported by checkpatch.pl:
WARNING: else is not generally useful after a break or return
235: FILE: drivers/staging/nvec/nvec.c:235
Signed-off-by: Pawel Lebioda
---
drivers/staging/nvec/nvec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/driver
Fix the following warning reported by checkpatch.pl:
WARNING: Possible unnecessary 'out of memory' message
811: FILE: drivers/staging/nvec/nvec.c:811
Signed-off-by: Pawel Lebioda
---
drivers/staging/nvec/nvec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/sta
On Sat, Jul 05, 2014 at 07:28:14AM +0300, Andrey Utkin wrote:
> See https://bugzilla.kernel.org/show_bug.cgi?id=79441
> ---8<---
> Made changes similar to 0ae89beb283a0db5980d1d4781c7d7be2f2810d6
>
Thanks for fixing this bug but the patch description is just a URL and a
git hash. Say something l
On Mon, 30 Jun 2014, Austin Schuh wrote:
> I think I might have an answer for my own question, but I would
> appreciate someone else to double check. If list_empty erroneously
> returns that there is work to do when there isn't work to do, we wake
> up an extra worker which then goes back to sleep
On Sat, 5 Jul 2014, Joe Perches wrote:
> > > I don't think %#p is valid so it
> > > shouldn't have been set by #.
> >
> > Huh? As recently as last Wednesday you pointed me at the specific commit
> > from Grant that made it valid (GCC format complaints aside).
>
> Those gcc complaints are prec
Verifying the email address is not 100% fool proof so it's not a massive
deal either way. The only reason I mentioned it here was because this
patch wasn't correct anyway and had to be redone regardless.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Sat, Jul 05, 2014 at 09:44:56PM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 5, 2014 at 9:23 PM, Dan Carpenter
> wrote:
> > On Sat, Jul 05, 2014 at 02:48:27PM +0200, Rickard Strandqvist wrote:
> >> From: Rickard Strandqvist
> >
> > These for lines are for when you are sending on someone els
On Wed, 2 Jul 2014, Tejun Heo wrote:
> > static inline bool try_to_freeze(void)
> > {
> > + kgr_task_safe(current);
> > +
> > if (!(current->flags & PF_NOFREEZE))
> > debug_check_no_locks_held();
> > return try_to_freeze_unsafe();
>
> Heh, I'm totally confu
print_nid_path has a possible buffer overflow if
struct nid_path.path values are > 256.
Avoid this and neaten the output to remove the leading ':'
Neaten debug_badness to always verify arguments.
Signed-off-by: Joe Perches
---
sound/pci/hda/hda_generic.c | 20 +++-
1 file chang
On Fri, Jul 04, 2014 at 09:47:53PM +0200, Fabian Frederick wrote:
> s/static_name/name_is_static
>
> Cc: Greg Kroah-Hartman
> Cc: Andrew Morton
> Cc: Tejun Heo
> Signed-off-by: Fabian Frederick
Acked-by: Tejun Heo
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscri
Hello,
MMC driver for JZ4740 SoC is currently relying on PIO mode only for
data transfers.
The patch that comes as a follow-up of this message allows the use of
DMA for data transfers.
Changes since v1:
- remove blank line added by mistake in jz_mmc_prepare_data_transfer().
According to the f
Until now the MMC driver for JZ4740 SoC was relying on PIO mode only
for data transfers.
This patch allows the use of DMA for data trasnfers in addition to PIO
mode by relying on DMA Engine.
DMA tranfers performance might be further improved by taking advantage
of the asynchronous request capabili
Hi Linus,
The following changes since commit 6c9d16178870315846faa1f59697b801e3fe0531:
Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes
(2014-06-25 20:27:15 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.gi
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
A few minor fixlets in ARM SoC irq drivers and a fix for a memory leak
which I introduced in the last round of cleanups :(
Thanks,
tglx
On Fri, 4 Jul 2014, Pavel Machek wrote:
> > Hi, why do you believe so? But it is not so important, see below.
>
> Because it is quite hard to prepare the patch, and there's not really
> enough documentation..? And given choice between "spend half an hour
> preparing patch" and "just reboot", peop
Commit-ID: 8844aad89ed61545b4db6a3467e1b21ca1c49460
Gitweb: http://git.kernel.org/tip/8844aad89ed61545b4db6a3467e1b21ca1c49460
Author: Keith Busch
AuthorDate: Mon, 30 Jun 2014 16:24:44 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 5 Jul 2014 21:42:08 +0200
genirq: Fix memory leak w
On Sat, Jul 5, 2014 at 9:23 PM, Dan Carpenter wrote:
> On Sat, Jul 05, 2014 at 02:48:27PM +0200, Rickard Strandqvist wrote:
>> From: Rickard Strandqvist
>
> These for lines are for when you are sending on someone else's behalf.
Or for when you are sending the patches from a different email addre
Following the name change of the NOP transceiver driver in commit
4525bee (usb: phy: rename usb_nop_xceiv to usb_phy_generic), make sure
to register the transceiver driver before calling usb_get_phy() to
avoid issues related to accessing its data structure while it was not
registered.
Signed-off-b
Hello,
The name of the NOP transceiver driver was changed during v3.16
release cycle from usb_phy_gen_xceiv to usb_phy_generic.
The patch that comes as a follow up of this message registers the NOP
transceiver driver before calling usb_get_phy() to avoid issues
related to accessing its data struc
Rename usb_nop_xceiv to usb_phy_generic in platform data to match the
name change of the nop transceiver driver in commit 4525bee (usb: phy:
rename usb_nop_xceiv to usb_phy_generic).
The name change induced a kernel panic due to an unhandled kernel
unaligned access while trying to dereference musb
Hello,
The name of the NOP transceiver driver was changed during v3.16
release cycle from usb_phy_gen_xceiv to usb_phy_generic.
The patch that comes as a follow up of this message renames
accordingly the NOP transceiver driver in JZ4740 platform data to fix
a subsequent kernel panic.
Changes sin
On Sun, Jul 06, 2014 at 12:34:14AM +0530, pawandeep oza wrote:
> no this is not a generic code bug, because only in this scenerio, problem
> might happen.
> because other core is plugged out and now there is no chance that it can
> release the spin_lock it would have held previously.
>
> so this c
On Sat, Jul 05, 2014 at 02:48:27PM +0200, Rickard Strandqvist wrote:
> From: Rickard Strandqvist
These for lines are for when you are sending on someone else's behalf.
>
> Variable ar assigned a value that is never used.
> I have also removed all the code that thereby serves no purpose.
>
> Th
On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero)
On Sun, Jul 06, 2014 at 12:20:03AM +0530, pawandeep oza wrote:
> preempt_check_resched would check TIF_NEED_RESCHED
> #define preempt_check_resched() \
> do { \
> if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \
> preempt_schedule(); \
> } while (0)
>
> there is a chance that just beofre we dis
On Sat, Jul 5, 2014 at 8:26 PM, Emil Goode wrote:
> We check that the struct vm_area_struct pointer vma is NULL and then
> dereference it a few lines below. The intent must have been to make sure
> that vma is not NULL and then to check the value from cpu_context() for
> the condition to be true.
On Fri, Jul 04, 2014 at 10:43:40PM -0700, Guenter Roeck wrote:
> On 07/04/2014 03:19 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.47 release.
> >There are 46 patches in this series, all will be posted as a response
> >to this one. If anyone has any iss
On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote:
> At Sat, 05 Jul 2014 18:21:04 +0900,
> Satoru Takeuchi wrote:
> >
> > Hi Greg,
> >
> > Add Takashi Iwai to this thread.
> >
> > At Sat, 05 Jul 2014 16:00:41 +0900,
> > Satoru Takeuchi wrote:
> > >
> > > At Fri, 04 Jul 2014 22:45:42
On Sat, Jul 05, 2014 at 02:58:28PM +0200, Takashi Iwai wrote:
> At Fri, 4 Jul 2014 15:19:48 -0700,
> Greg Kroah-Hartman wrote:
> >
> > 3.14-stable review patch. If anyone has any objections, please let me know.
>
> This turned to be not applicable to 3.14 and earlier, as mentioned in
> another
On Wed, Jul 2, 2014 at 6:17 AM, Will Deacon wrote:
> On Tue, Jul 01, 2014 at 07:43:32PM +0100, Liviu Dudau wrote:
>> Enhance the default implementation of pcibios_add_device() to
>> parse and map the IRQ of the device if a DT binding is available.
>>
>> Signed-off-by: Liviu Dudau
>> ---
>> drive
[+cc Rafael]
On Sat, Jul 05, 2014 at 12:57:36PM -0600, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> On Tue, Jul 01, 2014 at 12:46:18PM +0530, Vidya Sagar wrote:
> > commit 1a680b7c moved pcie_aspm_powersave_config_link() out of
> > pci_raw_set_power_state() to pci_set_power_state() which would enable
On Sun, Jul 06, 2014 at 12:20:03AM +0530, pawandeep oza wrote:
> Hi,
>
> I am referring to this version of spin lock apis.
>
> static inline void __raw_spin_lock(raw_spinlock_t *lock)
> {
> preempt_disable();
> spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
> LOCK_CONTENDED(lock, do_raw_spin_trylo
[+cc Matthew]
On Tue, Jul 01, 2014 at 12:46:18PM +0530, Vidya Sagar wrote:
> commit 1a680b7c moved pcie_aspm_powersave_config_link() out of
> pci_raw_set_power_state() to pci_set_power_state() which would enable
> ASPM. But, with commit db288c9c, which re-introduced the following check
> ./drivers
On Fri, Jul 4, 2014 at 8:32 PM, Mark Brown wrote:
> On Tue, Jul 01, 2014 at 09:03:59AM +0800, addy ke wrote:
>> In order to facilitate understanding, rockchip SPI controller IP design
>> looks similar in its registers to designware. But IC implementation
>> is different from designware, So we need
On Mon, Jun 30, 2014 at 05:45:20PM -0400, Murali Karicheri wrote:
> Keystone PCIe controller is based on v3.65 version of the
> designware h/w. Main differences are
> 1. No ATU support
> 2. Legacy and MSI irq functions are implemented in
> application register space
> 3.
On Sat, 2014-07-05 at 19:20 +0100, Maciej W. Rozycki wrote:
> On Sat, 5 Jul 2014, Joe Perches wrote:
> > I don't think %#p is valid so it
> > shouldn't have been set by #.
>
> Huh? As recently as last Wednesday you pointed me at the specific commit
> from Grant that made it valid (GCC format co
On Saturday 05 July 2014 13:13:01 Robert Jarzmik wrote:
> EXPORT_SYMBOL(get_clock_tick_rate);
>
> /*
> + * For non device-tree builds, keep legacy timer init
> + */
> +extern void pxa_timer_nodt_init(int irq, void __iomem *base,
> + unsigned long clock_tick_rate);
> +vo
We check that the struct vm_area_struct pointer vma is NULL and then
dereference it a few lines below. The intent must have been to make sure
that vma is not NULL and then to check the value from cpu_context() for
the condition to be true.
Signed-off-by: Emil Goode
---
v2: Updated the commit mes
On 07/05/2014 10:48 AM, Greg Kroah-Hartman wrote:
On Sat, Jul 05, 2014 at 10:46:46AM -0700, Greg Kroah-Hartman wrote:
On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote:
On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.4.97 rel
On Mon, Jun 30, 2014 at 05:45:15PM -0400, Murali Karicheri wrote:
> This patch add PCIe controller driver for Keystone SoCs. This
> is based on v2 of the series posted to the mailing list.
> Keystone PCI controller is based on version 3.65 of the DW
> hardware. This driver re-uses some of the DW co
On 07/05/2014 09:47 AM, Apelete Seketeli wrote:
Following the name change of the nop transceiver driver in commit
4525bee, make sure to register the transceiver driver before calling
Please also specify that commit's summary line in parens.
usb_get_phy() to avoid issues related to accessi
On Sat, 5 Jul 2014, Joe Perches wrote:
> > > I think it's a mistake and I agree.
> > >
> > > I submitted a patch to remove the prefix from %pad.
> > >
> > > https://lkml.org/lkml/2014/3/21/333
> >
> > Great! Your proposal looks good to me in principle, however you need to
> > factor in SPECI
On Sat, Jul 05, 2014 at 10:44:41PM +0530, pawandeep oza wrote:
> process calls sys_reboot and that process then stops other CPUs while those
> CPUs are within a spin_lock() region we can potentially encounter a
> deadlock
> scenario like below.
>
> CPU 0 CPU 1
> -
On Sat, 2014-07-05 at 18:39 +0100, Maciej W. Rozycki wrote:
> On Sat, 5 Jul 2014, Joe Perches wrote:
>
> > > One question though, does either of you or anybody else know why we're
> > > inconsistent about this 0x prefixing of virtual addresses vs physical
> > > addresses? Specifically %p vs e.
On Sat, Jul 05, 2014 at 10:55:57AM -0400, Ed Tomlinson wrote:
> Hi
>
> I have a raspberry PI sending its console to my box via a pl2303
What exact pl2303 is this? Can you provide the output from 'lsusb'?
> [5.184385] usbserial: USB Serial support registered for pl2303
> [5.184398] pl23
On Sat, Jun 28, 2014 at 11:44:43AM +0200, Fabian Frederick wrote:
> Fix checkpatch warning:
> "WARNING: debugfs_remove(NULL) is safe this check is probably not required"
>
> Cc: Bjorn Helgaas
> Cc: Ryan Desfosses
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Fabian Frederick
Applied to pci/
On Sat, Jul 05, 2014 at 11:41:26PM +0800, Axel Lin wrote:
> 2014-07-05 21:20 GMT+08:00 Beniamino Galvani :
> > This patch prepares support for other devices in the act88xx family of
> > PMUs manufactured by Active-Semi.
> >
> > http://www.active-semi.com/products/power-management-units/act88xx/
> >
On Sat, Jul 05, 2014 at 10:46:46AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote:
> > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> > >This is the start of the stable review cycle for the 3.4.97 release.
> > >There are 19 patches in this seri
On Thu, Jun 26, 2014 at 11:58:55AM -0700, Rajat Jain wrote:
> After following recent cleanups by Bjorn:
>
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/hotplug
>
> 2cc56f3 PCI: pciehp: Remove assumptions about which commands cause
> 40b9608 PCI: pciehp: Compute timeout
On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote:
> On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.4.97 release.
> >There are 19 patches in this series, all will be posted as a response
> >to this one. If anyone has any issu
On Sat, Jul 05, 2014 at 03:53:09PM +0900, Satoru Takeuchi wrote:
> At Fri, 04 Jul 2014 22:39:01 -0700,
> Guenter Roeck wrote:
> >
> > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.4.97 release.
> > > There are 19 patches in this seri
On Sat, 5 Jul 2014, Joe Perches wrote:
> > One question though, does either of you or anybody else know why we're
> > inconsistent about this 0x prefixing of virtual addresses vs physical
> > addresses? Specifically %p vs e.g. %pad.
>
> I think it's a mistake and I agree.
>
> I submitted a p
On Wed, Jun 25, 2014 at 11:26:44PM +0530, Kishon Vijay Abraham I wrote:
> [1] is split into separate series in order for individual subsystem
> Maintainers to pick up the patches. This series handles the PCIe
> support for DRA7.
>
> Rebased to 3.16-rc2.
>
> [1] -> https://lkml.org/lkml/2014/5/29/
On Sat, Jul 5, 2014 at 2:21 PM, Rickard Strandqvist
wrote:
> From: Rickard Strandqvist
>
> Variable ar assigned a value that is never used.
> I have also removed all the code that thereby serves no purpose.
>
> This was found using a static code analysis program called cppcheck
>
> Signed-off-by:
On Mon, Jun 23, 2014 at 04:36:25PM -0600, Alex Williamson wrote:
> This bridge sometimes shows up as a root complex device and sometimes
> as a discrete PCIe-to-PCI bridge. Testing indicates that in the
> latter case, we need to enable the PCIe bridge DMA alias quirk.
>
> Signed-off-by: Alex Will
This avoids handling gpiochip remove error in device
remove handler.
Signed-off-by: abdoulaye berthe
---
drivers/gpio/gpiolib.c | 24 +++-
include/linux/gpio/driver.h | 2 +-
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/driver
1 - 100 of 242 matches
Mail list logo
