Hi Russell,
any comment on this one?
Thanks,
Michal
On 09/04/2013 04:44 PM, Michal Simek wrote:
> This patch is inpired by the patch for drvdata
> "device-core: Ensure drvdata = NULL when no driver is bound"
> (sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
>
> Also it fixes all occurences
Le 12/09/2013 02:15, Benjamin Herrenschmidt a écrit :
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote:
I wonder why we don't start from entry 31 so we can actually make use of
that autodecrement. What will happen when we load the first normal TLB
entry later on? I don't see any setting
devm_iounmap is called automatically that's why remove it from the code
dev_set_drvdata(dev, NULL) is called by generic code
after device_release or on probe failure.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 28 ++--
1 file changed, 6 insertions(+), 22
Simplify driver probe and release function.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 123cd70..fd9c430 100644
--- a/drivers/video/xilinxfb.c
+++
s/op/pdev/ in xilinxfb_of_probe().
No functional chagnes.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 84c664e..123cd70 100644
---
Let me fix my mail first.. I was running out of time yesterday and so couldn't
frame things correctly :)
On 11 September 2013 17:29, Viresh Kumar wrote:
> Okay.. There are two different ways in which cpufreq_add_dev() work
> currently..
>
> Boot cluster (i.e. policy with boot CPU)
>
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Roger Quadros
[ Upstream commit 47a64a13d54f6c669b00542848d5550be3d3310e ]
Set the ehci->resuming flag for the port we receive a remote
wakeup on so that resume signalling can be
* Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 11, 2013 at 07:55:03AM +0200, Ingo Molnar escreveu:
> > 16645 perf_event_open(0x1eb7f00, 0x, 0, 0x, 0) = -1 EINVAL
> > (Invalid argument)
> >
> > Caused by:
> >
> > 575a9aab0f85 perf tools: Add attr->mmap2 support
> >
> > We
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
[ Upstream commit 5ec2481b7b47a4005bb446d176e5d0257400c77d ]
smp_call_function_* must not be called from softirq context.
But clock_was_set() which calls on_each_cpu()
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sami Rahman
[ Upstream commit 7681156982026ebf7eafd7301eb0374d7648d068 ]
Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
devices using customized Silicon Labs'
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Dan Williams
[ Upstream commit 4cf76df06ecc852633ed927d91e01c83c33bc331 ]
Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
interface protocols are unknown.
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Nicolin Chen
[ Upstream commit 2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 ]
Also fix return values for headphone switch updates.
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Barry Grussling
[ Upstream commit b579fa52f6be0b4157ca9cc5e94d44a2c89a7e95 ]
This patch adds support for the Schweitzer Engineering Laboratories
C662 USB cable based off the CP210x
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Vineet Gupta
[ Upstream commit e6c495a96ce02574e765d5140039a64c8d4e8c9e ]
zap_pte_range loops from @addr to @end. In the middle, if it runs out of
batching slots, TLB entries needs to
On Wed, Sep 04, 2013 at 02:18:46PM +0530, Raghavendra K T wrote:
> Signed-off-by: Raghavendra K T
> ---
> Changes in V2:
> Correction in the description of steal time and added msr info (Michael S
> Tsirkin)
Thanks. Some comments below:
> Documentation/virtual/kvm/cpuid.txt | 10 ++
Use devm_request_irq function.
Signed-off-by: Michal Simek
---
drivers/dma/pl330.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..58623dc 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Luiz Angelo Daros de Luca
[ Upstream commit 90625070c4253377025878c4e82feed8b35c7116 ]
This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
USB ID (0846:0110) to
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Jeff Skirvin
[ Upstream commit 96f15f29038e58e1b0a96483e2b369ff446becf1 ]
This commit fixes a race condition in the isci driver abort task and SSP
device task management path. The
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Eldad Zack
[ Upstream commit be2f93a4c4981b3646b6f98f477154411b8516cb ]
Return SNDRV_PCM_POS_XRUN (snd_pcm_uframes_t) instead of
SNDRV_PCM_STATE_XRUN (snd_pcm_state_t) from the pointer
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Saurav Kashyap
[ Upstream commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 ]
This fixes a regression where Xyratex controllers and disks were lost by the
driver:
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Alexandr \\\"Sky\\\" Ivanov"
[ Upstream commit ca24763588844b14f019ffc45c7df6d9e8f932c5 ]
Adding support for D-Link DWM-152/C1 and DWM-156/C1 devices.
DWM-152/C1:
T: Bus=01
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Josef Bacik
[ Upstream commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f ]
We aren't setting path->locks[level] when we resume a snapshot deletion which
means we won't unlock the buffer
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: William Gulland
[ Upstream commit 2c7b871b9102c497ba8f972aa5d38532f05b654d ]
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control
Using devres functions simplify driver error path.
- Use devm_kzalloc
- Use devm_request_irq
Signed-off-by: Michal Simek
---
---
drivers/uio/uio.c | 16
drivers/uio/uio_pdrv_genirq.c | 34 ++
2 files changed, 14 insertions(+), 36
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Jan Beulich
[ Upstream commit 093b9c71b6e450e375f4646ba86faed0195ec7df ]
Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure
linear area is big enough on RX")
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Johan Hovold
[ Upstream commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 ]
Allocated urbs and buffers were never freed on errors in open.
Cc: sta...@vger.kernel.org
Signed-off-by:
On 12 September 2013 06:13, Rafael J. Wysocki
wrote:
> Yes, if you can point to a specific driver having this problem.
There are so many of those (I know it because I went through almost all drivers
recently with my cleanup series): cpufreq-cpu0, omap-cpufreq,
exynos-cpufreq, etc..
They all do
On Thu, Sep 12, 2013 at 02:03:41PM +0900, Tetsuo Handa wrote:
> Herbert Xu wrote:
> > This way at least you'll have a working system until your initramfs
> > tool is fixed to do the right thing.
>
> Thank you. But it is module-init-tools-3.9-21.el6_4 in RHEL 6.4.
> We can't wait until Red Hat
As a rule its better not to break string (quoted inside "") in a print statement
even if it crosses 80 column boundary as that may introduce unwanted bugs and so
this patch rewrites one of the print statements..
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed,
With a recent change the logic here is changed a bit and I just figured out it
is something we don't want.
Consider we have four CPUs (0,1,2,3) managed by a policy and policy->cpu is set
to 0. Now we are suspending and hence we call __cpufreq_remove_dev_prepare() for
cpu 1, 2 & 3..
With the
Nobody except cpufreq_remove_dev() is calling __cpufreq_remove_dev() and so we
don't need separate routines here. Lets merge code from __cpufreq_remove_dev()
to cpufreq_remove_dev() and get rid of __cpufreq_remove_dev().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 26
This broke after a recent change "cedb70a cpufreq: Split __cpufreq_remove_dev()
into two parts" from Srivatsa..
Consider a scenario where we have two CPUs in a policy (0 & 1) and we are
removing cpu 1. On the call to __cpufreq_remove_dev_prepare() we have cleared 1
from policy->cpus and now on a
Hi Rafael/Srivatsa,
These are some last minute fixes for 3.12. I have found them while looking at
the code to fix the latest suspend/resume crashes we see (Reported by Stephen)..
I believe at some place these are behind those crashes, otherwise people with a
single cluster or single policy
We don't need a blank line just at start of a block, lets remove it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5a64f66..28477eb 100644
--- a/drivers/cpufreq/cpufreq.c
On 09/04/2013 02:18 PM, Raghavendra K T wrote:
Signed-off-by: Raghavendra K T
---
Changes in V2:
Correction in the description of steal time and added msr info (Michael S
Tsirkin)
Documentation/virtual/kvm/cpuid.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git
Herbert Xu wrote:
> This way at least you'll have a working system until your initramfs
> tool is fixed to do the right thing.
Thank you. But it is module-init-tools-3.9-21.el6_4 in RHEL 6.4.
We can't wait until Red Hat backports module-init-tools >= 3.11 to RHEL 6.x.
Since most people are
Hi Rafael, Toshi,
When we hot-add an ACPI0004 device, we got the following warning:
acpi ACPI0004:01: Attempt to re-insert
The ACPI0004 device is a System Board in Fujitsu server, which has two
numa nodes (processors and memory).
It seems that we reserved the ACPI_NOTIFY_DEVICE_CHECK
Hi Oleg,
On 09/09/2013 08:25 PM, Oleg Nesterov wrote:
On 09/09, Anton Arapov wrote:
On Sun, Sep 08, 2013 at 06:32:32PM +0200, Oleg Nesterov wrote:
Not sure, but I can be easily wrong... afaics we need something like below, no?
Anton?
Oleg, your guess is correct.
My original intention was to
On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote:
> (9/3/13 4:39 AM), Janani Venkataraman wrote:
>> Hello,
>>
>> We are working on an infrastructure to create a system core file of a
>> specific
>> process at run-time, non-disruptively. It can also be extended to a
>> case where
>> a process is able
On Mon, 2 Sep 2013 01:09:55 -0400 ycbzzj...@gmail.com wrote:
> From: Bian Yu
>
> When raid5 hit a fresh badblock, this badblock will flagged as unack
> badblock until md_update_sb is called.
> But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb
> in md_check_recovery, the
This removes two warnings where dma_addr_t variables were printed using
%x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t'
This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
dma_addr_t might then be 64-bit:
drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-sdma.c:1166:3: warning:
Actually, here it is, but not formatted properly
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 816d1a2..146e712 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,14 +240,14 @@ serial_omap_baud_is_mode16(struct
Hi all,
Please do not add any code for v3.13 to your linux-next included branches
until after v3.12-rc1 is released.
Changes since 20130911:
The akpm tree gained a conflict against Linus' tree.
I have created today's
On Wed, Sep 11, 2013 at 11:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 11, 2013 at 10:19:47PM +0300, Alexey Pelykh wrote:
>> On Wed, Sep 11, 2013 at 10:00 PM, Felipe Balbi wrote:
>> > On Wed, Sep 11, 2013 at 09:48:13PM +0300, Alexey Pelykh wrote:
>> >> On Wed, Sep 11, 2013 at 9:38 PM,
This resolves a warning where resource_size_t is larger than void *:
drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
Since iomem_base is a void *, casting to unsigned long is safe.
It's unclear to me that this comparison
On Wed, Sep 11, 2013 at 08:43:19PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I'm again having the boot failure problem due to commit 68411521 'Reinstate
> "crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform
> framework"' in linux.git .
OK, can you please try this patch on top
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/dec/tulip/de4x5.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Wed, Sep 11, 2013 at 08:38:32PM -0700, Eric W. Biederman wrote:
> Greg KH writes:
>
> > On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
> >> Hello,
> >>
> >> I'll send out multiple patchsets to separate out sysfs from driver
> >> core and kobject. The eventual goal is making
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/amd/sun3lance.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/amd/sun3lance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hello, Eric.
On Wed, Sep 11, 2013 at 08:39:27PM -0700, Eric W. Biederman wrote:
> @ns is more significant so it should come first.
>
> Where do we have the backwards convention of putting @name first?
Because @ns is optional and you end up with stupid stuff like
sysfs_xxx_ns(@param,
On Wed, Sep 11, 2013 at 08:37:23PM -0700, Eric W. Biederman wrote:
> At a practical level you probably just want to copy the good parts of
> the structure of sysfs, instead of attempting to share code.
>
> Sharing code is likely to get you into all kinds of problems with short
> term hacks.
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/ibm/ehea/ehea_main.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 7 +++
1 file changed, 3 insertions(+), 4
On 9/11/13 3:36 PM, Thavatchai Makphaibulchoke wrote:
> I seem to be seeing the same thing as Eric is seeing.
...
> For both filesystems, the security xattr are about 32.17 and 34.87 bytes
> respectively.
...
Can you triple-check the inode size on your fs, for good measure?
dumpe2fs -h
On Tue, Sep 10, 2013 at 05:44:15PM -0400, Vivek Goyal wrote:
> Hi,
>
> Matthew has been posting patches to lock down kernel either due to
> secureboot requirements or because of signed modules with signing
> enforced. In kernel lock down mode, kexec will be disabled and that
> means kdump will
Tejun Heo writes:
> Some internal sysfs functions which take explicit namespace argument
> are weird in that they place the optional @ns in front of @name which
> is contrary to the established convention. This is confusing and
> error-prone especially as @ns and @name may be interchanged
[ 29.804534] [ INFO: suspicious RCU usage. ]
[ 29.804539] 3.11.0+ #5 Not tainted
[ 29.804541] ---
[ 29.804545] security/apparmor/include/policy.h:363 suspicious
rcu_dereference_check() usage!
[ 29.804548]
[ 29.804548] other info that might help us debug
Greg KH writes:
> On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
>> Hello,
>>
>> I'll send out multiple patchsets to separate out sysfs from driver
>> core and kobject. The eventual goal is making sysfs modular enough so
>> that cgroup can replace its nightmarish cgroupfs
Tejun Heo writes:
> Hello,
>
> I'll send out multiple patchsets to separate out sysfs from driver
> core and kobject. The eventual goal is making sysfs modular enough so
> that cgroup can replace its nightmarish cgroupfs implementation which
> repeated and worsened all the past mistakes of
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/adi/bfin_mac.c.
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/adi/bfin_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On Wed, Sep 11, 2013 at 08:33:44PM -0700, Greg KH wrote:
> I have to wait for 3.12-rc1 to come out before applying anything, and
> then we will be at LinuxCon/Plumbers drinking^Wworking all next week, so
> it will be a bit before any of this could hit my tree.
Heh, sounds good. See you soon in
On Wed, Sep 11, 2013 at 11:23:16PM -0400, Tejun Heo wrote:
> Hello, Greg.
>
> > Nice job with these. Do you want me to add them to my tree for 3.13, or
> > do you want to take them through yours as you will be building on top of
> > them?
>
> I think it'll be best to route them through your
Looks like these were added to Documentation/printk-formats.txt but
not the in-file table.
Signed-off-by: Olof Johansson
---
lib/vsprintf.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..061bacb 100644
--- a/lib/vsprintf.c
+++
On Wed, 2013-09-11 at 23:36 +0200, Frederic Weisbecker wrote:
> On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote:
> > On Wed, 11 Sep 2013, Mike Galbraith wrote:
> >
> > > Mind saying why? To me, creating properties of exclusive sets of CPUs
> > > that the interface which
Hello, Greg.
> Nice job with these. Do you want me to add them to my tree for 3.13, or
> do you want to take them through yours as you will be building on top of
> them?
I think it'll be best to route them through your tree but maybe we
want to wait a bit before applying them?
Thanks!
--
From: Yu Chao
There is a performance problem: when all sbi->fs_lock are holded, then
all the following threads may get the same next_lock value from
sbi->next_lock_num
in function mutex_lock_op, and wait for the same lock(fs_lock[next_lock]),
it may cause performance reduce.
So we move the
>From 5a4b7340199b2d6ff15b6fc551b0ea3f2cc19b6e Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Wed, 11 Sep 2013 23:19:13 -0400
The pre-existing sysfs interfaces which take explicit namespace
argument are weird in that they place the optional @ns in front of
@name which is contrary to the
* Peter Zijlstra (pet...@infradead.org) wrote:
> On Wed, Sep 11, 2013 at 08:48:11PM -0400, Mathieu Desnoyers wrote:
> > Thoughts ?
>
>
> struct foo {
> ...
> };
>
> spinlock_t foo_lock;
> unsigned int foo_head = 0;
> unsigned int foo_tail = 0;
> struct foo foo_array[2];
>
> void
Hi Chao,
On 09/12/2013 10:40 AM, 俞超 wrote:
> Hi Gu
>
>> -Original Message-
>> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
>> Sent: Wednesday, September 11, 2013 1:38 PM
>> To: jaegeuk@samsung.com
>> Cc: chao2...@samsung.com; shu@samsung.com;
>> linux-fsde...@vger.kernel.org;
On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
> Hello,
>
> I'll send out multiple patchsets to separate out sysfs from driver
> core and kobject. The eventual goal is making sysfs modular enough so
> that cgroup can replace its nightmarish cgroupfs implementation which
> repeated
Currently, if module's refcount is not zero during the unload,
it waits there until the user decreases that refcount. Assume
we have two modules (A & B), there are no symbol relationship
between each other. module B is module A's user, if the end
user tries to unload module A first wrongly, it
On Thursday 12 September 2013 04:44 AM, Sarah Sharp wrote:
Hi Kumar,
I was waiting until after the 3.12 merge window to queue this patch, but
Xenia noticed that the xhci_readl functions can completely go away and
be replaced by standard readl/writel operations. She's posted a
patchset to do
On Wed, Sep 11, 2013 at 7:20 PM, Peter Zijlstra wrote:
>
> I split the thing up into two macros GEN_UNARY_RMWcc and
> GEN_BINARY_RMWcc which ends up being more readable as well as smaller
> code overall.
Yes, that looks like the right abstraction level. Powerful without
being complicated.
> I
Hi Gu
> -Original Message-
> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> Sent: Wednesday, September 11, 2013 1:38 PM
> To: jaegeuk@samsung.com
> Cc: chao2...@samsung.com; shu@samsung.com;
> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
On 09/11/2013 09:25 PM, Theodore Ts'o wrote:
> On Wed, Sep 11, 2013 at 03:48:57PM -0500, Eric Sandeen wrote:
>>
>> So at this point I think it's up to Mak to figure out why on his system,
>> aim7 is triggering mbcache codepaths.
>>
>
> Yes, the next thing is to see if on his systems, whether or
Hello,
I'll send out multiple patchsets to separate out sysfs from driver
core and kobject. The eventual goal is making sysfs modular enough so
that cgroup can replace its nightmarish cgroupfs implementation which
repeated and worsened all the past mistakes of sysfs. This patchset
is first of
The pre-existing sysfs interfaces which take explicit namespace
argument are weird in that they place the optional @ns in front of
@name which is contrary to the established convention. For example,
we end up forcing vast majority of sysfs_get_dirent() users to do
sysfs_get_dirent(parent, NULL,
There's no reason for sysfs to be calling ktype->namespace(). It is
backwards, obfuscates what's going on and unnecessarily tangles two
separate layers.
There are two places where symlink code calls ktype->namespace().
* sysfs_do_create_link_sd() calls it to find out the namespace tag of
the
sysfs ns (namespace) implementation became more convoluted than
necessary while trying to hide ns information from visible interface.
The relatively recent attr ns support is a good example.
* attr ns tag is determined by sysfs_ops->namespace() callback while
dir tag is determined by
The expansion of to_sysfs_dirent() contains an unncessary trailing
semicolon making it impossible to use in the middle of statements.
Drop it.
Signed-off-by: Tejun Heo
---
fs/sysfs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index
For some unrecognizable reason, namespace information is communicated
to sysfs through ktype->namespace() callback when there's *nothing*
which needs the use of a callback. The whole sequence of operations
is completely synchronous and sysfs operations simply end up calling
back into the layer
The way namespace tags are implemented in sysfs is more complicated
than necessary. As each tag is a pointer value and required to be
non-NULL under a namespace enabled parent, there's no need to record
separately what type each tag is or where namespace is enabled.
If multiple namespace types
Some internal sysfs functions which take explicit namespace argument
are weird in that they place the optional @ns in front of @name which
is contrary to the established convention. This is confusing and
error-prone especially as @ns and @name may be interchanged without
causing compilation
On Wed, Sep 11, 2013 at 10:19 PM, Neil Horman wrote:
> On Wed, Sep 11, 2013 at 07:54:28PM +0800, Ming Lei wrote:
>> On Sat, Sep 7, 2013 at 3:36 AM, Neil Horman wrote:
>> > The direct firmware loading interface is a bit quiet about failures.
>> > Failures
>>
>> Because there are several
On Wed, Sep 11, 2013 at 11:45:19AM +0300, Jani Nikula wrote:
> On Wed, 11 Sep 2013, Aaron Lu wrote:
> > It is possible the i915 driver decides not to register a backlight
> > interface for the graphics card for some reason(memory allocation failed
> > or it knows the native control does not work
On Thu, 2013-09-12 at 03:33 +0800, Stephen Warren wrote:
> On 09/11/2013 05:19 AM, Bill Huang wrote:
> > diff --git a/drivers/cpufreq/tegra20-cpufreq.c
> > b/drivers/cpufreq/tegra20-cpufreq.c
>
> > +static struct cpufreq_frequency_table freq_table[] = {
> > + { .frequency = 216000 },
> > + {
On Wed, Sep 11, 2013 at 04:02:14PM -0700, Linus Torvalds wrote:
> On Wed, Sep 11, 2013 at 11:59 AM, Peter Zijlstra wrote:
> >
> > OK, stripped it down further, I couldn't quite see how to collapse the
> > unary and binary operator variants though :/
>
> Ok, this looks pretty good. I assume it
Hillo Mel
On Tue, Sep 10, 2013 at 5:32 PM, Mel Gorman wrote:
> Currently automatic NUMA balancing is unable to distinguish between false
> shared versus private pages except by ignoring pages with an elevated
> page_mapcount entirely. This avoids shared pages bouncing between the
> nodes whose
Hi Kim
> -Original Message-
> From: Kim Jaegeuk [mailto:jaegeuk@gmail.com]
> Sent: Wednesday, September 11, 2013 9:15 PM
> To: chao2...@samsung.com
> Cc: ???; 谭姝; linux-fsde...@vger.kernel.org;
linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: Re:
Hi Everyone,
Please ignore this mail. Version information, 'v3' is missing in the
subject.
Fixed mail has just sent. Please find '[PATCH v3 4/4]' in your mailbox.
Sorry for the inconvenience.
Best regards,
Milo
On 09/12/2013 10:34 AM, Milo Kim wrote:
Bindings for LP3943 MFD, GPIO and PWM
Current equation on the comment is wrong.
For linear mapping starting from 0, the equation is (maxV-minV)/stepV + 1.
Since the linear mapping for PALMAS is not all starting from 0, the equation
on the comment is not useful and misleading. Thus remove it.
Signed-off-by: Axel Lin
---
On 09/03/2013 05:12 PM, Maximiliano Curia wrote:
¡Hola Peter!
El 2013-08-19 a las 08:25 -0400, Peter Hurley escribió:
My primary concern is canonical readers not become stuck with a full
read buffer, even with bogus input data (IOW, that an error condition will
not prevent a reader from making
Bindings for LP3943 MFD, GPIO and PWM controller are added.
And LP3943 driver document is added also.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
Documentation/00-INDEX |2 +
Bindings for LP3943 MFD, GPIO and PWM controller are added.
And LP3943 driver document is added also.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
Documentation/00-INDEX |2 +
This is the other of the LP3943 MFD driver.
LP3943 can be used as a PWM generator, up to 2 channels.
* Two PWM generators supported
* Supported PWM operations
request, free, config, enable and disable
* Pin assignment
A driver data, 'pin_used' is checked when a PWM is requested.
If the
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output,
LP3943 has 16 output pins which can be used as GPIO expander and PWM generator.
* Regmap I2C interface for R/W LP3943 registers
* Atomic operations for output pin assignment
The driver should check whether requested pin is available or not.
If the pin is already used, pin request returns as
LP3943 is an integrated device capable of driving 16 output channels.
It can be used for GPIO expander and PWM generators.
LP3493 registers are controlled via the I2C interface.
This patch-set consists of four parts - MFD, GPIO, PWM and documents.
Major updates in v3:
* MFD
Lee Jones pointed
On Wed, Sep 11, 2013 at 08:48:11PM -0400, Mathieu Desnoyers wrote:
> Thoughts ?
struct foo {
...
};
spinlock_t foo_lock;
unsigned int foo_head = 0;
unsigned int foo_tail = 0;
struct foo foo_array[2];
void foo_assign(struct foo f)
{
spin_lock(_lock);
foo_head++;
Hi Eric,
(Sorry for the delay, please see below)
On Sat, Aug 31, 2013 at 06:44:39PM -0700, Eric W. Biederman wrote:
> Djalal Harouni writes:
[...]
> > Yes Kees,
> >
> > I did try a year ago to adapt the exec_id from grsecurity and failed
> > (and failed again to resend - not enough resources):
1 - 100 of 1346 matches
Mail list logo
