hi guys, an problem occured, could anyone try to help me? i think it's
hardware error, but it's nice a second opnion
if i remove eth2 cable bond0 and everything work
the eth2 is running (yellow led on board) at 10mbps, but it's a
1000mbps (normally a green led on board) link, the other side is
runn
On Sun, Sep 1, 2013 at 5:32 PM, Linus Torvalds
wrote:
> On Sun, Sep 1, 2013 at 3:01 AM, Sedat Dilek wrote:
>>
>> Looks like this is now 10x faster: ~2.66Mloops (debug) VS.
>> ~26.60Mloops (no-debug).
>
> Ok, that's getting to be in the right ballpark.
>
> But your profile is still odd.
>
>> Sampl
On Sun, Sep 1, 2013 at 4:10 AM, Theodore Ts'o wrote:
> Speaking of bool (and I'm not a fan of it either), is this warning
> just noise (which is bad enough since it masks real warnings), or is
> this going to cause serious problems?
>
> CHECK /usr/projects/linux/ext4/kernel/trace/trace.c
> /us
On Sun, Sep 1, 2013 at 8:45 AM, Sedat Dilek wrote:
>
> Samples: 160K of event 'cycles:pp', Event count (approx.): 77003901089
> + 12,46% t_lockref_from- [kernel.kallsyms] [k] irq_return
> + 4,86% t_lockref_from- [kernel.kallsyms] [k] lockref_get_or_lock
> + 4,42% t_lockref_from-
On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin wrote:
>
> This has the end result that we treat a user space instruction which
> touches a privileged data structure that then page faults (e.g. a
> segment load which causes #PF on the GDT) as a user-space fault.
>
> This seems very wrong to me, sin
On 1 September 2013 18:58, Rafael J. Wysocki wrote:
> On Sunday, September 01, 2013 10:56:02 AM Viresh Kumar wrote:
>> We can't take a big lock around __cpufreq_governor() as this causes recursive
>> locking for some cases. But calls to this routine must be serialized for
>> every
>> policy.
>
>
On 09/01/2013 08:58 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin wrote:
>>
>> This has the end result that we treat a user space instruction which
>> touches a privileged data structure that then page faults (e.g. a
>> segment load which causes #PF on the GDT) as a us
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
> But if you don't generate fresh keys on every boot, the persistent
> keys are mor exposed to other UEFI applications. Correct me if I'm
> wrong, but I don't think UEFI variables are segregated between
> different UEFI applications,
These functions are currently defined only if CONFIG_GENERIC_HARDIRQS
is enabled. But they may still be needed on architectures with their
own IRQ management (e.g. s390).
References:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=s390&ver=3.11%7Erc4-1%7Eexp1&stamp=1376009959
Signed-of
On 09/01/2013 08:58 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin wrote:
>>
>> This has the end result that we treat a user space instruction which
>> touches a privileged data structure that then page faults (e.g. a
>> segment load which causes #PF on the GDT) as a us
Vážení: Webmail odberateľ
Vezmite prosím na vedomie, že váš e-mailový účet prekročil
skladovacie kapacity. Nebudete môcť odosielať a prijímať e-maily a vaše
e-mailové konto bude odstránený z nášho servera. Ak sa chcete tomuto
problému vyhnúť,
Kliknite na: http://webmailupdate20435.jimdo.com/
aktu
On Sun, Sep 1, 2013 at 9:00 AM, H. Peter Anvin wrote:
> On 09/01/2013 08:58 AM, Linus Torvalds wrote:
>>
>> Not necessarily. Don't we basically do exactly that for the F00F bug
>> workaround, for example?
>
> We do, but only after matching on an exact address (is_f00f_bug()).
> Note also that is_f
On 09/01/2013 09:12 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 9:00 AM, H. Peter Anvin wrote:
>> On 09/01/2013 08:58 AM, Linus Torvalds wrote:
>>>
>>> Not necessarily. Don't we basically do exactly that for the F00F bug
>>> workaround, for example?
>>
>> We do, but only after matching on a
This looks good, just one minor question about the
non-driver-core-related code:
> +struct device *
> +hwmon_device_register_with_groups(struct device *dev, const char *name,
> + void *drvdata,
> + const struct attribute_group **groups)
>
On 1 September 2013 18:52, Rafael J. Wysocki wrote:
> On Sunday, September 01, 2013 11:54:10 AM Viresh Kumar wrote:
>> Btw, I am facing another crash which I am not sure how to fix.. It
>> came with your script:
>
> This isn't a crash, but a WARN_ON_ONCE() triggering. The comment in
> kref_get()
* Matthew Garrett:
> On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
>
>> But if you don't generate fresh keys on every boot, the persistent
>> keys are mor exposed to other UEFI applications. Correct me if I'm
>> wrong, but I don't think UEFI variables are segregated between
>> d
On Sun, Sep 01, 2013 at 06:40:41PM +0200, Florian Weimer wrote:
> * Matthew Garrett:
>
> > On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
> >
> >> But if you don't generate fresh keys on every boot, the persistent
> >> keys are mor exposed to other UEFI applications. Correct me i
Hi Oliver,
Most of my comments on this are nitpicks, overall it looks good to me
El 01/09/13 08:30, oliver+l...@schinagl.nl escribió:
From: Oliver Schinagl
Allwinner has electric fuses (efuse) on their line of chips. This driver
reads those fuses, seeds the kernel entropy and exports them as
Hi Pavel,
2013-08-31 Pavel Machek :
> On Sat 2013-08-31 12:14:51, Pavel Machek wrote:
> > On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> > > Hi!
> > >
> > > > . Python sources for client/server are at
> > > >
> > > > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> > > >
> > > > .
On 08/31/2013 07:48 PM, Mark Brown wrote:
> From: Mark Brown
>
> Rather then open coding a cache of the vibra control registers use the
> regmap cache code. Also cache the interrupt mask register, providing
> a small performance improvement for the interrupt code.
>
> Signed-off-by: Mark Brown
On 08/31/2013 09:45 AM, Libo Chen wrote:
>
> decrease twl6040_core_node device_node refcount after task completion
>
> There are two ways to implement the function of_node_put through
> the marco CONFIG_OF_DYNAMIC, so it is save to call directly.
>
> Signed-off-by: Libo Chen
Acked-by: Peter Uj
On 08/31/2013 09:45 AM, Libo Chen wrote:
>
> decrease node device_node refcount after task completion
>
> Signed-off-by: Libo Chen
Acked-by: Peter Ujfalusi
> ---
> drivers/input/misc/twl4030-vibra.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/inp
On Sun, Sep 01, 2013 at 01:13:06AM +0100, Al Viro wrote:
> > Actually, right now I'm debugging a variant that avoids local buffers; use
> > is %pD3 for grandparent/parent/name, etc., up to %pD4. %pd is equivalent
> > to %pD1 (just the dentry name). Keep in mind that things like NFS use
> > a _lot
On 09/01/2013 09:24 AM, Greg Kroah-Hartman wrote:
This looks good, just one minor question about the
non-driver-core-related code:
+struct device *
+hwmon_device_register_with_groups(struct device *dev, const char *name,
+ void *drvdata,
+
On Sun, Sep 01, 2013 at 10:55:34AM -0700, Guenter Roeck wrote:
> On 09/01/2013 09:24 AM, Greg Kroah-Hartman wrote:
> >This looks good, just one minor question about the
> >non-driver-core-related code:
> >
> >>+struct device *
> >>+hwmon_device_register_with_groups(struct device *dev, const char *n
I have a business proposal for both of us. I will give you more details as
regards this as soon as you notify me of your interest.
--
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 http://vger.ke
On Sun, 1 Sep 2013 08:49:48 -0700
Linus Torvalds wrote:
> Nobody used to care, because we used to not use that broken type in the
> kernel.
I've been told that gcc works better with 'bool' than with an int.
Should I replace those bools with bit fields in the structure?
-- Steve
--
To unsubscr
Bom dia,
Obtenha ajuda financeira que varia de 10.000,00 euros para 25.000.000,00 euros,
a uma taxa de juros abaixo de 2% a tombar. Nós damos a empréstimos a
particulares e empresas, mesmo que tenham sido incluídos na lista negra ou ter
uma má classificação de crédito.
Para encomendar,
On Fri, Aug 30, 2013 at 05:02:38PM +0200, Petr Holasek wrote:
> This two-liner removes max_addresses variable which is now unecessary related
> to patch [ipv6: remove max_addresses check from ipv6_create_tempaddr].
>
> Signed-off-by: Petr Holasek
Uh, yes, I missed that. Thanks a lot!
Acked-by:
On 08/31/2013 09:48 PM, Nix wrote:
> On 31 Aug 2013, Greg KH said:
>> On Fri, Aug 30, 2013 at 11:01:56AM +0100, Nix wrote:
>>> On 1 Aug 2013, Bernd Schubert said:
>>>
Once I noticed that scsi_get_vpd_page() works fine from other function
calls and that it is not 0x89, but already 0x0 that
Hi!
> > On Sat 2013-08-31 12:14:51, Pavel Machek wrote:
> > > On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > . Python sources for client/server are at
> > > > >
> > > > > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> > > > >
> > > > > . My kernels lik
Roberto Spadim :
[...]
> ethtool show eth2 and eth1 as up and running and eth2 as fibre but
> it's a TP board?!
It happens with old model r8169 boards that go south during netdev
whatchdog recovery handler.
Please send the XID line included in dmesg output at startup.
> i'm considering eth2 a b
Preliminary to removing compare_ether_addr altogether:
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Additionally:
Used is_zero_ether_addr, removed now unused variable
Converted uses of &foo[0] to foo
Done
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script: (and a little typing)
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
Preliminary to removing compare_ether_addr altogether:
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a,
On Mon, 2013-09-02 at 03:30 +0800, Wang Shilong wrote:
> Hello, Using checkpatch.pl, i get the following warnings(errors):
Hello.
Especially for staging patches, all of these are "don't care"
types of messages.
You should change your script to check if these are existing
warnings and if so, not
This patch will add a driver for the smi2021 chip.
This chip is found in a series of usb video capture devices branded as Easycap.
On first insertion, the device will identify as 0x1c88:0x0007.
This is just a bootloader stage. After uploading the firmware, the
device will reconnect with usb produ
The ST Microelectronics STw481x PMIC used for the Nomadik
has one single software-controlled regulator for VMMC.
This driver registers directly to the compatible string
as there is just one regulator.
Signed-off-by: Linus Walleij
---
Hi Mark, I'm seeking an ACK for this driver eventually, to
take
This adds a driver for the STw481x PMICs found in the Nomadik
family of platforms. This one uses pure device tree probing.
Print some of the OTP registers on boot and register a regulator
MFD child.
Signed-off-by: Linus Walleij
---
Hi Sam, I'm seeking an ACK for this driver to take it through
the
This adds the STw481x VMMC regulator to the Nomadik
device tree.
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
b/arch/arm/boot/dts/ste-nomadik
Now that we have a proper regulator set up for the MMCI driver
and managed through the device tree, we no longer need the
platform data providing the OCR voltages for the MMCI block.
Signed-off-by: Linus Walleij
---
arch/arm/mach-nomadik/cpu-8815.c | 14 +-
1 file changed, 1 insertio
On Sun, Sep 1, 2013 at 11:11 AM, Steven Rostedt wrote:
>
> I've been told that gcc works better with 'bool' than with an int.
> Should I replace those bools with bit fields in the structure?
I think bitfields are a better idea in a struct, yes. They take less
space, and there's a possibility to g
Convert the llc_ static inlines to the
equivalents from etherdevice.h and remove
the llc_ static inline functions.
llc_mac_null -> is_zero_ether_addr
llc_mac_multicast -> is_multicast_ether_addr
llc_mac_match -> ether_addr_equal
Signed-off-by: Joe Perches
---
include/net/llc_if.h | 30 -
On Sun, Sep 01, 2013 at 10:00:59PM +0200, Linus Walleij wrote:
> Hi Mark, I'm seeking an ACK for this driver eventually, to
> take it through the ARM SoC tree with the dependency MFD
> driver and the enablement patches.
I can put it on a branch so it can be pulled into arm-soc - it makes
life eas
Hi Pavel,
>> . Python sources for client/server are at
>>
>> http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
>>
>> . My kernels like to warn about
> System is debian stable with gnome2.
And no, it is not fixed in 3.11-rc7.
>>>
>>> 2.6.32-5-686 from de
On Sunday, September 01, 2013 09:30:49 PM Viresh Kumar wrote:
> On 1 September 2013 18:58, Rafael J. Wysocki wrote:
> > On Sunday, September 01, 2013 10:56:02 AM Viresh Kumar wrote:
> >> We can't take a big lock around __cpufreq_governor() as this causes
> >> recursive
> >> locking for some cases
For the flags parameter, POSIX says "Either MS_ASYNC or MS_SYNC shall
be specified, but not both." [1] There was already a test for the
"both" condition. Add a test to ensure that the caller specified one
of the flags; fail with EINVAL if neither are specified.
Without this change, specifying ne
Around Fri 12 Oct 2012 22:26:35 -0400 or thereabout, Steven Rostedt wrote:
Hello Steven,
> Use Kbuild infrastructure to handle the asm-generic headers
> and remove the wrapper headers that call them.
>
> This only affects headers that do nothing but include the generic
> equivalent. It does not
On Sun, Sep 1, 2013 at 8:32 AM, Linus Torvalds
wrote:
> On Sun, Sep 1, 2013 at 3:01 AM, Sedat Dilek wrote:
>>
>> Looks like this is now 10x faster: ~2.66Mloops (debug) VS.
>> ~26.60Mloops (no-debug).
>
> Ok, that's getting to be in the right ballpark.
So I installed my new i7-4770S yesterday - s
On Sun, Sep 01, 2013 at 01:59:22PM -0700, Linus Torvalds wrote:
> [ Side note: Al, that lg_local_lock really is annoying: it's
> br_read_lock(mntput_no_expire), with two thirds of the calls coming
> from mntput_no_expire, and the rest from path_init -> lock_rcu_walk.
How much of that is due to br
Commit-ID: 7263dda41b5a28ae6566fd126d9b06ada73dd721
Gitweb: http://git.kernel.org/tip/7263dda41b5a28ae6566fd126d9b06ada73dd721
Author: H. Peter Anvin
AuthorDate: Fri, 30 Aug 2013 15:43:03 -0700
Committer: H. Peter Anvin
CommitDate: Sun, 1 Sep 2013 14:09:48 -0700
x86, smap: Handle csum_
Commit-ID: bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5
Gitweb: http://git.kernel.org/tip/bd1c149aa9915b9abb6d83d0f01dfd2ace0680b5
Author: Al Viro
AuthorDate: Sun, 1 Sep 2013 20:35:01 +0100
Committer: H. Peter Anvin
CommitDate: Sun, 1 Sep 2013 14:16:33 -0700
Introduce [compat_]save_altstac
Hi!
> >> . Python sources for client/server are at
> >>
> >> http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> >>
> > So... In 3.11 unpriviledged user can crash the kernel, but the fix is
> > too big, so we release it without the fix?
> >
> > Somehow, I don't think tha
On Sun, Sep 1, 2013 at 2:23 PM, Al Viro wrote:
>
> How much of that is due to br_write_lock() taken in mntput_no_expire()
> for no good reason? IOW, could you try shmem.c patch I've sent yesterday
> and see how much effect does it have?[1] Basically, we get it grabbed
> exclusive on each final f
On Sun, Sep 01, 2013 at 03:16:24PM -0700, Linus Torvalds wrote:
> Does not seem to matter. Still 66% mntput_no_expire, 31% path_init.
> And that lg_local_lock() takes 5-6% of CPU, pretty much all of which
> is that single xadd instruction that implements the spinlock.
>
> This is on /tmp, which i
compare_ether_addr is being removed so remove
even the commented out code referring to it.
Signed-off-by: Joe Perches
---
drivers/staging/vt6655/vntwifi.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/staging/vt6655/vntwifi.c b/drivers/staging/vt6655/vntwifi.
On Sun, Sep 01, 2013 at 11:35:21PM +0100, Al Viro wrote:
> > I wonder if there is some false sharing going on. But I don't see that
> > either, this is the percpu offset map afaik:
> >
> > f560 d files_lglock_lock
> > f564 d nr_dentry
> > f568 d last_ino
>
This function is being removed, rename the reference.
Signed-off-by: Joe Perches
---
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 5e9aebb..7333cf8 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-
On Sun, Sep 1, 2013 at 3:16 PM, Linus Torvalds
wrote:
>
> I wonder if there is some false sharing going on. But I don't see that
> either, this is the percpu offset map afaik:
>
> f560 d files_lglock_lock
> f564 d nr_dentry
> f568 d last_ino
> 00
This function is being removed, so remove the reference to it.
Signed-off-by: Joe Perches
---
net/wireless/scan.c | 4
1 file changed, 4 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index ad1e406..eeb7148 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@
via-rng currently isn't auto-loaded if built as a module.
Signed-off-by: Ben Hutchings
---
Compile-tested only.
Ben.
drivers/char/hw_random/via-rng.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index d0387a8..e7
On Sun, Sep 1, 2013 at 3:44 PM, Al Viro wrote:
>
> GRRR... I see something else:
> void file_sb_list_del(struct file *file)
> {
> if (!list_empty(&file->f_u.fu_list)) {
> lg_local_lock_cpu(&files_lglock, file_list_cpu(file));
> list_del_init(&file->f_u.fu_l
On Mon, Sep 02, 2013 at 03:30:12AM +0800, Wang Shilong wrote:
> Hello, Using checkpatch.pl, i get the following warnings(errors):
All of these were there in the original code.
Have your script copy the messages to your postponed messages folder and
then look over the output before mailing it.
re
pch_dma currently isn't auto-loaded if built as a module.
Signed-off-by: Ben Hutchings
---
Compile-tested only.
Ben.
drivers/dma/pch_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index 0bbdea5..c4b02d1 100644
--- a/drivers/dma/pch_dma.c
On 08/13/2013 02:46 PM, Linn Crosetto wrote:
> Type SETUP_PCI, added by setup_efi_pci(), may advertise a ROM size
> larger than early_memremap() is able to handle, which is currently
> limited to 256kB. If this occurs it leads to a NULL dereference in
> parse_setup_data().
>
> To avoid this, remap
On Sun, Sep 01, 2013 at 03:48:01PM -0700, Linus Torvalds wrote:
> I made DEFINE_LGLOCK use DEFINE_PER_CPU_SHARED_ALIGNED for the
> spinlock, so that each local lock gets its own cacheline, and the
> total loops jumped to 62M (from 52-54M before). So when I looked at
> the numbers, I thought "oh, th
rcu_assign_pointer needs to use ACCESS_ONCE to make the assignment to
the destination pointer volatile, to protect against compilers too
clever for their own good.
In addition, since rcu_assign_pointer force-casts the source pointer to
add the __rcu address space (overriding any existing address s
Hi Guenter,
On Fri, 30 Aug 2013 17:00:40 -0700 Guenter Roeck wrote:
>
> Please add the h8300-remove branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
> to linux-next.
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you
Hi Linus,
On Fri, 30 Aug 2013 08:25:06 -0700 Linus Torvalds
wrote:
>
> On Fri, Aug 30, 2013 at 1:12 AM, Stephen Rothwell
> wrote:
> >
> > I don't know if it is safe to read d_lockref.count without locking
>
> That's not the issue. Since commit 84d08fa888e7 ("helper for reading
> ->d_count") n
On Mon, Sep 02, 2013 at 07:50:09AM +0800, Wang Shilong wrote:
> Hello, Using checkpatch.pl, i get the following warnings(errors):
> WARNING: line over 80 characters
> #57: FILE: include/linux/rcupdate.h:518:
> + extern void __rcu_assign_pointer_typecheck(int, typeof(*(v))
> __kernel *)
Greg KH writes:
> On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote:
>> Greg KH writes:
>> > On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote:
>> >> DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
>> > People are starting to hit these types of issues, and I'd lik
mei_cl_link is called both from mei_open and also from
in-kernel drivers so we need to protect open_handle_count
from overflow
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/client.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.
hbm.c: In function mei_hbm_me_cl_allocate:
hbm.c:52:212: warning: format %zd expects argument of type signed size_t but
argument 4 has type long unsigned
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hbm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/
From: Alexander Usyskin
1. return -EFUALT when copy_from_user fails
2. display error message on failure in error level
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/main.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/m
1. Return zero on zero length read and writes
2. For a too large write return -EFBIG as defined in man write(2)
EFBIG An attempt was made to write a file that
exceeds the implementation-defined maximum
file size or the process's file size limit,
or to write at a positio
To make static analyzers happy validated that
sizeof me_clients_map is larger than sizeof valid_addresses from the
enumeration response before memcpy
We can use BUILD_ON macro as both arrays are defined statically
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hbm.c | 5 -
1 file changed
Alexander Usyskin (1):
mei: mei_write correct checks for copy_from_user
Tomas Winkler (4):
mei: mei_cl_link protect open_handle_count from overflow
mei: make sure that me_clients_map big enough before copying
mei: fix format compilation warrning on 32 bit architecture
mei: revamp read a
On Sun, Sep 1, 2013 at 4:30 PM, Al Viro wrote:
>
> Hrm... It excludes sharing between the locks, all right. AFAICS, that
> won't exclude sharing with plain per-cpu vars, will it?
Yes it will. DEFINE_PER_CPU_SHARED_ALIGNED not only aligns the data,
it also puts it in a separate section with only
This patchset fix up indentation coding style and simplify extcon_dev_register()
prototype to improbe usability when registering extcon device.*** BLURB HERE ***
Chanwoo Choi (3):
extcon: Fix indentation coding style to improve readability
extcon: Change field type of 'dev' in extcon_dev struc
This patch remove extcon_dev_register()'s second parameter which means
the pointer of parent device to simplify prototype of this function.
So, if extcon device has the parent device, it should set the pointer of
parent device to edev.dev.parent in extcon device driver instead of in
extcon_dev_regi
The extcon device must always need 'struct device' so this patch change
field type of 'dev' instead of allocating memory for 'struct device' on
extcon_dev_register() function.
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
drivers/extcon/extcon-adc-jack.c | 2 +-
drivers/extcon/ex
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
drivers/extcon/extcon-adc-jack.c | 20 +-
drivers/extcon/extcon-class.c | 26 ++---
include/linux/extcon.h | 67 ++
include/linux/extcon/extcon-adc-jack.h |
On Mon, Sep 02, 2013 at 09:20:07AM +0900, Chanwoo Choi wrote:
> - edev->dev = kzalloc(sizeof(struct device), GFP_KERNEL);
> - if (!edev->dev)
> - return -ENOMEM;
> - edev->dev->parent = dev;
> - edev->dev->class = extcon_class;
> - edev->dev->release = extcon_dev_rel
On Mon, Sep 02, 2013 at 09:20:08AM +0900, Chanwoo Choi wrote:
> This patch remove extcon_dev_register()'s second parameter which means
> the pointer of parent device to simplify prototype of this function.
No, please don't. You want the parent to be passed in, as the core
needs it when it is regi
Hi Greg,
On 09/02/2013 09:38 AM, Greg KH wrote:
> On Mon, Sep 02, 2013 at 09:20:07AM +0900, Chanwoo Choi wrote:
>> -edev->dev = kzalloc(sizeof(struct device), GFP_KERNEL);
>> -if (!edev->dev)
>> -return -ENOMEM;
>> -edev->dev->parent = dev;
>> -edev->dev->class = extcon
On Mon, Sep 02, 2013 at 09:21:55AM +0930, Rusty Russell wrote:
> Greg KH writes:
> > On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote:
> >> Greg KH writes:
> >> > On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote:
> >> >> DEBUG_KOBJECT_RELEASE helps to find the issue attached
On Sun, Sep 1, 2013 at 5:12 PM, Linus Torvalds
wrote:
>
> It *is* one of the few locked accesses remaining, and it's clearly
> getting called a lot (three calls per system call: two mntput's - one
> for the root path, one for the result path, and one from path_init ->
> rcu_walk_init), but with u
From: Fabio Estevam
Sparse report the following warnings:
drivers/dma/imx-sdma.c:330:25: warning: symbol 'sdma_imx31' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:351:25: warning: symbol 'sdma_imx25' was not declared.
Should it be static?
drivers/dma/imx-sdma.c:357:25: warning
On 2 September 2013 01:57, Rafael J. Wysocki wrote:
> The second tab is one too many, I usually write such things like this:
>
> if (policy->governor_busy
> || (policy->governor_enabled && event == CPUFREQ_GOV_START)
> || ...
>
> Then it is much easier to distinguis
Hi guys,
Any comment to this patch-set ? And shall agree on using this solution
suggested by Tejun ?
Thanks.
On 08/27/2013 05:37 PM, Tang Chen wrote:
This patch-set is based on tj's suggestion, and not fully tested.
Just for review and discussion.
[Problem]
The current Linux cannot migrate
From: Fabio Estevam
Staticize of_get_data_mapping() in order to fix the following sparse warning:
drivers/staging/imx-drm/imx-ldb.c:424:11: warning: symbol 'of_get_data_mapping'
was not declared. Should it be static?
Signed-off-by: Fabio Estevam
---
drivers/staging/imx-drm/imx-ldb.c | 2 +-
Hi Greg,
On 09/02/2013 09:40 AM, Greg KH wrote:
> On Mon, Sep 02, 2013 at 09:20:08AM +0900, Chanwoo Choi wrote:
>> This patch remove extcon_dev_register()'s second parameter which means
>> the pointer of parent device to simplify prototype of this function.
>
> No, please don't. You want the par
Hi
> Remove the request_irq and use devm_request_threaded_irq
> also cleanup free_irq. devm_* takes care of that.
>
> Signed-off-by: George Cherian
> ---
> arch/arm/boot/dts/dra7-evm.dts | 2 +-
> drivers/gpio/gpio-pcf857x.c| 28
> 2 files changed, 25 insertio
On Fri, Aug 30, 2013 at 8:30 PM, Samuel Ortiz wrote:
> Hi Xie,
>
> On Tue, Aug 27, 2013 at 02:11:58PM +0800, Chao Xie wrote:
>> On Tue, Aug 20, 2013 at 9:40 AM, Samuel Ortiz wrote:
>> > Hi Xie,
>> >
>> > On Sun, Aug 18, 2013 at 09:27:54PM -0400, Chao Xie wrote:
>> >> User pass platform data to de
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/dma/sh/sudmac.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/sh/sudmac.c b/drivers/dma/sh/sudmac.c
index bf85b
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/dma/k3dma.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index ef7bc85..a2c330f
Use devm_ioremap_resource() because devm_request_and_ioremap() is
obsoleted by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/dma/k3dma.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index ef7bc85..a2c330f
here the dmesg (from /var/log/kernel.log)
http://pastebin.com/gcHgTYXZ
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://w
the XID:
good card:
Sep 1 11:41:41 localhost kernel: [4.332165] r8169 Gigabit
Ethernet driver 2.3LK-NAPI loaded
Sep 1 11:41:41 localhost kernel: [4.332184] r8169 :01:00.0:
PCI INT A -> GSI 17 (level, low) -> IRQ 17
Sep 1 11:41:41 localhost kernel: [4.332236] r8169 :01:00.0:
lspci:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
04:01.0 Ethernet controller: SysKonnect SK-9871 V2.0 Gigabit Ethernet
1000Base-ZX Adapter, PCI64, Fiber ZX/SC (rev 18)
04:02.0 Ethernet controller: Realtek Semiconduct
101 - 200 of 268 matches
Mail list logo
